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Abstract of DE1 9807872 

The method involves one unit managing an 
associated number equal to some or all of a total 
number of configurable elements. 
Reconfiguration requests are sent from the 
elements to the unit. The unit accepts no further 
requests and changes during processing; loads 
yet to be loaded configuration data of earlier 
requests from an intermediate memory into the 
configurable element; and converts the current 
request to a definite identifier or ID. The ID is 
converted to the address in the unit's memory of 
the configuration data to be loaded if the data 
exists in the memory. The data are requested 
from a superior unit if not present in the unit's 
memory. The data are loaded if the element can 
accept them. Data which cannot be accepted are 
placed in temporary memory. When configuration 
data have been fully processed, new requests 
can be accepted, until when the configuration 
data yet to be loaded from earlier request are 
loaded into the configurable elements. 
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Beschreibung 
Hintergrund der Erfindung 
Stand derTechnik 

Der Stand der Technik, welcher diese Patentschrift zugrundeliegt, ist durch die Patentanmeldung 196 54 846.2-53 
(Verfahren zum selbstandigen dynamischen Umladen von DatenfluBprozessoren (DFPs) sowie Bausteinen mil zwei- 
oder mehrdimensionaler programmierbaren Zellmatrix (FPGAs, DKjAs, o.dgl.) und der Patentanmeldung 196 54 
10 593.5-53 (Umkonfiguriemngs Verfahren fur programmierbare Bausteine zur Laufzeit) beschrieben. Darin wind ein \fer- 
fahren zur Konfiguration und Umkonfiguration von DFPs, sowie FPGAs, DPGAs und ahnlichen Bausteinen nach dem 
Stand der Technik, beschrieben, bei dem ein separat ausgestalteter zentral iibergeordneter Mikrokontroller-ahnhcher 
Baustein die Verteilung von Konfigurationsdaten an mehrere untergeordnete, weitgehend passive Steuereinheiten tiber- 
nimmt. 

15 

Probleme 

Durch den Einsatz einer zentralen und globalen Einheit, welche die Rekonfiguration von Teilen eines oder mehrerer 
Bausteine steuert, kommt es zu Engpassen, wenn viele verschiedene Rekonfigurauons-Anfragen auf einmal behandelt 

20 werden miissen. Die Vorteile der ParaUelitat, der beschriebenen Bausteine, wird durch eine solche zentrale Einheit stark 
eingeschrankt, da er den typischen "Flaschenhals" darstellt und die Verarbeitung der Daten dadurch erheblich verlang- 
samt. Weiterhin ist die Zuordnung der Ereignisquelle zu der zu ladenden Konfiguration problematisch, da mit absoluten 
Adressen des Konfigurationsspeichers gearbeitet wird. Die Rekonfigurations-Einheit muB also eine Art Speicherverwal- 
tungssystem beinhalten, welche, ahnlich wie in einem Betriebssystem, mitprotokolliert, welche Speicherbereich von 

25 welcher Konfiguration benutzt werden. 

Verbesserung durch die Erfindung, Aufgabe 

Die Grundaufgabe der vorliegenden Erfindung ist eine Einheit - im Folgenden Konfigurationstabelle (CT) genannt 
30 die hierarchisch aufgebaut ist und auf jeder Ebene mehrfach vorkommen kann, wobei sich die Zahl der CIs von der un- 
tersten Hierarchiestufe zur obersten so verringert, daB auf der hochsten Ebene genau eine CT vorhanden ist. Jede CT 
konfiguriert und kontrolliert unabhangig von anderen und parallel eine Mehrzahl von konfigurierbaren Elementen 
(CELs). CTs hoherer Hierarchiestufen konnen Konfigurationsroutinen fur tieferliegende Cft zwischenspeichem. Beno- 
tigen mehrere der tieferliegenden CTs ein und dieselbe Konfigurationsroutine, wird diese bei einer hdherliegenden CT 
35 zwischengespeichert und von den einzelnen CTs abgerufen, wobei die hSherliegende CT die betreffende Konfigurations- 
routine nur ein Mai aus einem globalen gemeinsamen Konfigurationsspeicher abruft, wodurch ein Cache-Efifekt erzielt 
wird. Abseits konfigurierbarer Bausteine kann die vorliegende Erfindung als Cacheverfahren fur Instruktions- und Da- 
tencache in Mikroprozessoren, DFP oder dgl. mit mehreren Rechenwerken eingesetzt werden. Dabei konnen, je nach 
Anwendung, einige der im Folgenden beschriebenen Einheiten entfallen (z. B. FELMO), am hierarchischen Aufbau an- 
40 dert sich jedoch grundlegend nichts. Deshalb wird dieser Einsatz als eine Teilmenge betrachtet und nicht weiter darauf 
eingegangen. 

Beschreibung der Erfindung 

Anstatt wie bisher eine zentrale und globale Einheit in einen Baustein zu integrieren, welche alle Konfigurations-An- 
forderungen bearbeitet, existieren nun eine Mehrzahl von hierarchisch (Baum-/Waldstruktur) angeordneten akti ven Ein- 
heiten, welche diese Aufgabe ubernehmen konnen. Dabei wird eine Anforderung von der tiefesten Ebene (den Blattern 
in der Hierarchie) nur dann an die nachst hoher gelegene Ebene weitergeleitet, wenn die Anforderung nicht bearbeitet 
werden konnte. Diese Schritte werden fiir alle vorhandenen Ebenen wiederholt, bis die hochst gelegene Ebene erreicht 
ist. 

Die hochst gelegene Ebene ist an einen intemen oder extemen ubergeordneten Konfigurationspeicher angeschlossen, 
der alle jemals fiir diesen Programlauf, benotigten Konfigurationsdaten enthalt. 

Durch die Baumstruktur der Konfigurationseinheiten wird eine Art Cacheing der Konfigurationsdaten erreicht. Zu- 
griffe auf Konfigurationen finden hauptsachlich lokal statt. Im ungiinsligsten Fall muB eine Konfiguration aus den uber- 
geordneten Konfigurationsspeicher geladen werden, falls die betreffenden Daten in keiner der hierarchisch angeordneten 
CTs vorhanden sind. 

Die Grundlagen der CT 

60 Eine Konfigurationstabelle (CT) ist eine aktive Einheit, die auf Synchronisationssignale, sogenannten Trigger (siehe 
DE 197 04 728.9), reagiert. Die Trigger werden von einer zwei- oder mehrdimensionalen Matrix aus elektronischen 
Baugruppen, fiir gewohnlich arithmentischen oder logischen Einheiten, Adressgeneratoren (siehe DE 196 54 595.1-53), 
Recheneinheiten (siehe DE 196 51 075.9), o.a. - im Folgenden konfigurierbare Elemente (CEL) genannt - generiert. An- 
hand des auftretenden Trigger wird eine bestimmte Aktion innerhalb der CT ausgelost. Dabei ist es Aufgabe der CT die 

65 Steuerung einer Mehrzahl von CELs zu ubemehmen und deren arithrnetischen und/oder logischen Opcrationen zu be- 
stimmen. Insbesondere miissen CELs, entsprechend DE 19651 075.9 konfiguriert und umkonfiguriert werden. Diese 
Aufgabe iibemimmt eine CT, indem sie eine Mehrzahl von moglichen Konfigurationsroutinen (KK), die ihrerseits je- 
weils aus einer Mehrzahl von einzelnen Konfigurationsworten (KW) bestehen, verwaltet und eine Mehrzahl von CELs 
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aufgrund von TYiggerbedingungen mil einer oder mehrerer der KP konfigurieren. Dabei erhalt eine CEL jeweils eines 
oder mehrere der Konfigurauonsworte, die mit der Adresse der zu konfigurierenden CEL versehen sind. Eine KR muB 
dabei vollstandig und korrekt auf eine Mehrzahl von CELs abgebildet werden, wobei mehrere CELs zu Gruppen zusam- 
mengefaBt sein konnen; die mit jeweils unterschiedlichen, aber vollstandig ausgefuhrten KRs konfiguriert werden. Dabei 
sind alle CELs in einer Gruppe so verschaltet, daB nach Feststellung einer notwendigen Umkonfigurierung alle gruppier- 5 
ten CELs durch ein gemeinsames Signal (ReConfig) mitgeteilt wird, daB jede CEL die Datenverarbeitung zu beenden 
und in einen umkonfigurierbaren Zustand iiberzugehen hat. 

Grundlagen der daedlockfreien Umkonfiguralion 

10 

Bei zur Laufzeit umkonfigurierbaren Systemen tritt das Problem auf, daB das System in einen Zustand gelangen kann, 
in dem jeweils zwei Teile aufeinander warten und somit eine klassische Deadlock Situation eingetreten ist. 

Dieses Problem kbnnte vermieden werden, indem eine neue Konfiguration immer nur ganz oder gar nicht in das Sy- 
stem geladen wird, oder eine Art Timeout- Verfahren eingesetzt wird. 

Dadurch entstehen ein Reihe von Nachteilen (benotigter Platz, Laufzeit etc.) und Problemen, wie zum Beispiel: 15 

- Vorgehen, falls eine Konfiguration nicht geladen werden kann. 

- Verwaltung der Reihenfolge, in der die Konfigurationen geladen werden 

- Performance Einbruch, da andere Konfigurationen, welche eventuell in die CELs geladen werden konnten, nicht 
beachtet werden. 20 



Mit dem folgend beschriebenen Verfahren konnen diese Probleme beseitigt werden. Es wird von einem DFP System 
nach DE 196 51 075.9 ausgegangen. 

Von einer CEL aus, wird ein Trigger-Signal, wie in der DE 1 97 04 728.9 beschrieben, an eine CT gesendet Diese CT 
stellt die Triggerquelle fest und wahlt durch eine Look-Up Tabelle eine zu ladende Konfiguration (KR) aus. Die einge- 25 
henden Triggersignale werden gesperrt, es werden keine weiteren Trigger bis zur kompletten Abarbeitung der aktuellen 
Konfiguration akztepiert. Eine Konfiguration besteht aus mehreren Befehlen, welche an eine Menge von CELs ubertra- 
gen wird. In einem zur Laufzeit konfigurierbaren System ist allerdings nicht sichergestellt, daB jeder Konfigurations-Be- 
fehl (KW) auch ausgefiihrt werden kann. Dies kann zum Beispiel daran scheitem, daB das adressierte konfigurierbare 
Element (CEL) seine Aufgabe noch nicht beendet hat und somit keine neuen Konfigurationsdaten entgegen nehmen 30 
kann. Um einen Performance Einbruch zu verhindern, werden alle Konfigurationsbefehle, welche nicht abgearbeitet 
werden konnten, entsprechend eines FIFOs hinter den letzten sich in einem - nachfolgend naher beschrieben - speziellen 
Speicher (FILMO) befindenden Konfigurationsbefehl geschrieben. Danach wird der nachsten Konfigurationsbefehl, 
nach dem gleichen Verfahren, abgearbeitet. Dies wiederholt sich solange, bis das Ende einer Konfiguration erreicht 
wurde. 35 

Danach geht die CT, wieder in den Zustand iiber, in dem sie Trigger-Signale akzeptiert, um eventuell weiter Konfigu- 
rationen zu laden. 

Eine Priorisierung der zu ladenden Konfigurationen wird erreicht, indem die CT den Speicher FILMO durchlauft, be- 
vor die eigentlich zu ladende Konfiguration bearbeitet wird. Durch eine FIFOahnliche Struktur des FILMO wird sicher- 
gestellt, daB KW, welche wahrend vorhergehenden TViggeranforderungen nicht vollstandig abgearbeitet werden konn- 40 
ten, automatisch eine hohere Prioritat vor den neu abzuarbeitenden WK erhalten. Bei der Abarbeitung des Speichers 
(FILMO) wird jedes durch einen Konfigurationsbefehl adressierte konfigurierbare Element (CEL) zuerst getestet, ob es 
sich im Zustand "umkonfigurierbar" befindet. Ist dieser Zustand "umkonfigurierbar", werden die Daten ubertragen und 
aus dem Speicher FILMO geloscht. Ist der Zustand "nicht umkonfigurierbar", bleiben die Daten im FILMO und werden 
beim nachsten Durchlauf erneut abgerarbeitet. Die CT verarbeitet den nachsten Eintrag im FILMO. Dies wiederholt sich 45 
solange, bis das Ende des FILMO erreicht ist. Danach wird die eigentliche, durch das Auftreten des Trigger-Signals ak- 
tivierte Konfiguration abgearbeitet. Der Aufbau des FILMOs entspricht dabei dem FIFO Prinzip, das heifit, es werden die 
altesten Eintrage zuerst verarbeitet. 

Die ubrigen, nicht beteiligten konfigurierbaren Elemente arbeitet wahrend dieser Phase parallel weiter und wird nicht 
in ihrer Funktion beeinfluBt. Dadurch kann der Fall eintreten, daB wahrend die CT den FILMO abarbeitet, eine oder meh- 50 
rere konfigurierbaren Elemente (CELs) in den Zustand "umkonfigurierbar" ubergehen. Da die CT sich mit der Abarbei- 
tung an einer beliebigen Stelle innerhalb des FILMOs befinden kann, konnte folgender Fall eintreten: Die CT versucht 
einen ersten Befehl abzuarbeiten dessen adressiertes konfigurierende Element (CEL) sich nicht in dem Zustand "umkon- 
figurierbar" befindet Die CT fahrt somit mit dem nachsten Befehl (KW) fort Zur selben Zeit gehen ein oder mehrere 
konfigurierbaren Elemente in den Zustand "umkonfigurierbar" iiber, darunter auch das konfigurierbare Element, welches 55 
durch den ersten Konfigurationsbefehl hatte beschrieben werden konnen. Die CT verarbeitet einen zwei ten Konfigurati- 
onsbefehl (KW), welcher das gleiche konfigurierbare Element (CEL) benutzt, wie der erste Konfigurationsbefehl, aller- 
dings aus einer anderen Konfiguration stammt. Zu diesem Zeitpunkt, befindet sich das konfigurierbare Element (CEL) in 
dem Zustand "umkonfigurierbar" und der Befehl kann erfolgreich abgerarbeitet werden. 

Durch diesen Ablauf ist nicht mehr sichergestellt, daB die Konfiguration, welche zuerst geladen werden sollte, auch 60 
tatsachlich zuerst fertiggestellt wird. Es konnen nun zwei teilweise fertige Konfigurationen existieren, welche jeweils 
konfigurierbare Elemente der anderen Konfiguration benotigen, um vollstandig geladen zu werden. Eine klassiche De- 
adlock-Situation ist eingetreten. 

In Fig. 18 ist dieser Zustand dargestellt. Konfiguration A und Konfiguration B sollen konfiguriert werden. Die CT hat 
den schraffierten Teil von Konfiguration A und Konfiguration B bereits geladen. Konfiguration A benotigt zur Fertigstel- 65 
lung noch den hell-doppelt schraffierten Bereich von Konfiguration B, und Konfiguration B benotigt zur Fertigstellung 
noch den dunkel-doppelt schraflierten Bereich von Konfiguration A. Da beide Konfigurationen noch nicht vollstandig 
abgeschlossen sind, und somit auch nicht funktionsfahig, tritt fur keine der beiden Konfigurationen der Terminierungs- 
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zustand ein, in dem eine der beiden Konfigurationen entfemt wiirde. Beide Konfigurationen warten darauf, daB die noch 
benotigten konfigurierbaren Elemente freigegeben werden. 

In dem vorliegenden Verfahren wind ein Deadlock verhindert, indem die CT vor der Abarbeitung des FTLMOs die Zu- 
stande aller konfigurierbarer Elemente erfafit und danach bis zur Beendigung des \fcrgangs keine Anderungen mehr zu- 
5 laBt, bzw. auftretende Anderungen ignoriert Die CT arbeitet nur auf Basis der erfaBten Zustanden und nicht mil den ak- 
tuellen Zustanden der konfigurierbaren Elemente. Dadurch ist sichergestellt, daB jeder zu bearbeitende Befehl (KW) den 
gleichen Zustand der konfigurierbaren Elemente (CELs) vorfindet. Dieser Schritt schlieBt nicht aus, daB ein oder mehrere 
konfigurierbaren Elemente wahrend der Abarbeitung des FILMOs, in den Zustand "umkonfigurierbar" ubergehen. Diese 
Anderung ist fiir die CT wahrend der Verarbeitung lediglich nicht sofort sichtbar, sondern erst zu Beginn des nachsten 
10 Durchlaufs. 

Um die Problematik der Umkonfiguration nochmals zu verdeutlichen wird foigendes Beispiel gegeben: 
Eine Matrix aus CELs ist unkonfiguriert und im RESET-Zustand. Jede CEL ist in der Lage anzuzeigen, ob sie sich in ei- 
nem umkonfigurierbaren Zustand befindet. AUe CELs in der Matrix sind bereit konfiguriert zu werden; befinden sich also 
in einem umkonfigurierbaren Zustand. Eine erste Konfigurationsroutine (KR1) wird geladen, wobei die Matrix nicht 
15 vollstandig benutzt wird. Die konfigurierten CELs heben die Anzeige, daB sie sich in einem konfigurierbaren Zustand be- 
finden auf. In einen Teil der noch nicht konfigurierten CELs wird eine zweite, von der Ersten unabhangigen, Konfigura- 
tionsroutine (KR2) geladen. Eine dritte Konfiguration kann nicht geladen werden, da diese CELs der ersten und/oder 
zweiten Konfigurationsroutine (KR3) benotigt, die sich aber in keinem umkonfigurierbaren Zustand befinden, da sie be- 
nutzt werden. 

20 KR3 muB so lange angehalten werden, bis die benotigten CEL freigegeben wurden, d. h. KR1 und KR2 terminiert ha- 
ben. Wahrend der Ausfuhrung von KR1 und KR2 kommt eine Ladeanforderung fur eine vierte Konfigurationsroutine 
(KR4) und eine fiinfte Konfigurationsroutine (KR5) hinzu, die alle nicht sofort geladen werden konnen, da sie CELs be- 
nutzen, die von KR1 und KR2 verwendet werden. KR3 und KR4 benutzen teilweise die selben CELs, KR5 benutzt keine 
der CELs von KR3 und KR4. 

25 Um KR3-5 ordentlich nachzuladen existieren folgende Forderungen: 

1 . KR3-5 sollen so geladen werden, daB die zeitliche Reihenfolge gemaB den Ladeanforderungen moglichst beibe- 
halten wird. 

2. Moglichst viele KR die unabhangig von einander sind, also keine gemeinsamen CELs besitzen, sollen geladen 
30 werden, um ein HochstmaB an Parallelitat zu erhalten. 

3. Die KRs durfen sich nicht gegenseitig blockieren, d. h. KR3 ist teilweise geladen, kann jedoch nicht weiter ge- 
laden werden, da andere CELs durch die teilweise geladene KR4 blockiert sind; wahrend KR4 auch nicht weiter ge- 
laden werden kann, da wiederum benotigte CELs durch KR3 blockiert sind. Dies fuhrt zu einer typische Deadlock- 
Situation. 

35 4. Dem Compiler, der die KRs generiert hat ist es nicht moglich das zeitliche Zusammenspiel der KRs zu erkennen 

und so aufzulosen, daB es zu keiner Konfliktsituation kommt. 

Dabei soli das Verhaltnis zwischen den Aufwand fur eine zu realisierende Schaltung und eines optimalen Ergebnisses 
moglichst gut sein, d. h. Ziel der Erfindung ist es mit moglichst geringem Aufwand eine flexible, parallele, Daedlock- 
40 freie Konfiguration zu ermoglichen, die mit wenig Zeit- und Rechenaufwand durchgefuhrt werden kann. Dabei mUssen 
folgende Grundprobleme gelost werden: 

- Wiirde nur KR3 geladen werden, ware das Verfahren Daedlock-frei, doch nicht optimal, da auch KRS geladen 
werden konnte. 

45 - Wird KR3 geladen, KR4 nicht, jedoch KR5 muB KR4 so vorgemerkt werden, daB es bei einem nachfolgenden 

Ladevorgang die hochste Prioritat besitzt, was einen hohen Verwaltungsaufwand bedeutet. 

Zur Losung dieser und der Eingangs genannten Aufgaben dient die vorliegende Erfindung: 

50 CACHE-PRINZIP 

Die CT-Struktur ist hierarchisch aufgebaut, d. h. es existieren in einem Baustein mehrere CT-Ebenen. Die Anordnung 
entspricht vorzugsweise einer Baumstruktur (CT-Tree). Dabei ist der Wurzel-CT (Root-CT) der externe Konfigurations- 
speicher (ECR) zugeordnet, wahrend den Blattern die konfigurierbaren Elemente (CELs) zugeordnet sind. Den CIs der 
55 mittleren Ebenen sind jeweils die konfigurierbaren Elemente zugeordnet, die sich auf derselben Hierarchiestufe befin- 
den. 

Jeder CT ist ein lokaler intemer Speicher zugeordnet. Dieser Speicher wird nur geloscht, wenn neu zu speichemde 
KRs keinen Platz mehr haben. Dabei erfolgt das Loschen KR-weise, anhand einer Loschstrategie, so daB bestenfalls nur 
die KR geloscht werden, die nicht mehr angefordert werden. Ebenfalls werden die KR einzeln geloscht, nur genau so 

60 viele, daB genau so viel Speicher frei ist, wie notwendig ist um die neu zu ladende KR in den Speicher zu schreiben. Da- 
durch wird erreicht, daB moglichst viele KR in dem Speicher verbleiben. 

Der Vorteil liegt darin, daB jede, einer beliebigen CTx untergordente CT, die sich also weiter oberhalb im CT-Baum 
befindet eine KR, die in der CTx gespeichert ist, nicht von dem extemen Konfigurationsspeicher ECR anfordert, sondern 
direkt von CTx erhalt. Dadurch ergibt sich eine Cachestruktur liber mehrere Ebenen. Dadurch wind der Obertragungsauf- 

65 wand im CT-Baum und ins besondere die benotigte Speicherbandbreite des ECR erheblich gesenkL Auf Basis dieser 
Struktur ergeben sich auch moglich e Loschstrategien, die allerdings je nach Anwendung empirisch festgelegt werden 
sollten. Eine Moglichkeiten sind: 
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- Loschen des altesten Eintrage 

- L6schen der kleinsten Eintrage 

- Loschen der groBten Eintrage 

- Loschen der am seltensten abgerufenen Eintrage. 

5 

Der Grundaufbau einer CT 

Die nachfolgende Ubersicht iiber die CT gibt einen ttberblick iiber die einzelnen Baugruppen. Die detailierle Be- 
schreibung der Baugruppen wind im Folgenden gegeben. 10 

Kern einer CT ist die Steuer-Statemachine (CTS) die samtliche Abarbeitungen von Konfigurationsroutinen (KRs) 
steuerl. Der CTS zugeordnet ist, der Garbage-Kollektor (GC), der das Entfernen von KR aus dem Speicher (CTR) der CT 
steuert; das FTLMO, das die Verwaltung der noch abzuarbeitenden KWs ilbernimmt und die LOAD-Statemachine, die 
das Laden von KRs steuert. 

Der Speicher (CTR) ist als gewohnlicher Schreib-Lese-Speicher ausgestaltet, wobei alle technisch moglichen Imple- IS 
mentierungen zum Einsatz komrnen konnen, und wird zur lokalen Speicherung von KRs fur die jeweilige CT und deren 
untergeordnete CTs verwendet. Als Sonderfall kann der Speicher (CTR) auch als ROM, EPROM, EEPROM, Flash- 
ROM o. a. ausgestaltet sein, um den Baustein mit einer festen, ASTC oder PLD-Shnlichen (siehe Stand der Tfechnik) 
Funktion zu versehen. 

Zur Generierung der CTR-Adressen werden vier als ladbare Zahler ausgestaltete Pointer verwendet: 20 

1. Free-Pointer (FP): Zeigt auf den ersten freien Speicherplatz hinter der letzte KR im CTR. 

2. Garbage-Pointer (GP): Zeigt auf einen durch den Garbage-Kollektor (GC) zu entfernenden Eintrag aus dem 
CTR. 

3. Move-Pointer (MP): Zeigt auf eine Speicherstelle im CTR, von der ein giiltiges, nicht zu entfemendes Konfigu- 25 
rations wort (KW), also einen Eintrag eines KR, an den durch GP definierten Eintrag kopiert/bewegt wird. 

4. Program-Pointer (PP): Zeigt auf das momentan von der CTS ausgefuhrten KW. 

KW werden iiber ein Ausgabe-Interface (OUT) an die zugehorenden CELs weitergegeben. Die CELs quittieren, so- 
fem sie sich in einem umkonfigurierbaren Zustand befinden den Empfang der KW. Wird ein KW nicht quittiert, wird es 30 
in einem HFO-ahnlichen Speicher (FELMO), zeitweise zwischengespeichert, um zu einem spateren Zeitpunkt, ohne den 
Program-Pointer zu benutzen, erneut an die adressierte CEL geschrieben zu werden. 

Eine AufForderung zur Abarbeitung eines KR erhalt die CTS durch Triggersignale. Die Triggersignale durchlaufen 
eine Maske, das ist ein Filter, der unerwiinschte Trigger ausfiltert (ausmaskiert). Eine Maske kann nach dem Stand der 
Technik durch UND-Gatter (AND) aufgebaut werden, die einen Trigger mit einem Freigabe-Signal UND-verkntipft. Die 35 
Trigger werden iiber einen priorisierten Round-Robin-Arbiter (SCRR-ARB) in Binarsignale umgewandelt. Ein priori- 
sierter Round-Robin- Arbiter verkniipfl den Vorteil der Gleichberechtigung eines Round-Robin- Arbiters mit der Erken- 
nung der nachsten Freigabe in einem Takt, also dem Vorteil eines Prioritats- Arbiter. 

Die maskierten Trigger werden als Adresse auf eine erste Lookup-Tabelle (LUT1) geschaltet, das ist ein Speicher, der 
dem als Adresse eingehenden Trigger das ID der betreffenden KR zuordnet und auf den Datenleitungen ausgibt. 40 

In einer zweiten Lookup-Tabelle (LUT2) wird die ID der KR der Adresse des Speicherplatzes der KR im CTR zuge- 
ordnet. Die zweite Lookup-Tabelle wird nicht nur zur Zuordnung von Trigger-Signalen verwendet, vielmehr benutzen ei- 
nige Befehle, die einen ID als Parameter verwenden die LUT2 ebenfalls zur Adresszuordnung. 

Die Zuordnung der Trigger-Signale zu den betreffenden IDs wird iiber den nachfolgend beschriebenen Befehl "REFE- 
RENCE" in die LUT1 eingetragen. Die Verwaltung der LUT2, also die Zuordnung der IDs zu den Adressen im CTR, ge- 45 
schieht automatisch durch die CTS und den GC. 

Zum besseren Verstandnis der CT ist im Folgenden ein moglicher Grundbefehlssatz dargestellt: 

1. BEGIN <ID> 

50 

Durch BEGIN <ID> wird der Anfang einer Konfigurationsroutine gekennzeichnet. <ID> gibt die eindeutige Identifi- 
kationsnummer der Konfigurationsroutine an. 

2. STOP 

55 

Durch STOP wird das Ende einer Konfigurationsroutine gekennzeichnet. An dieser Stelle beendet die Konfigurauons- 
tabelle (CT) die Abarbeitung der Konfigurationsroutine. Der Garbage-Kollektor (GC) beendet das Entfernen von Eintra- 
gen dieser Konfigurationsroutine. 

3. EXECUTE <ED> 60 

Springt zum Beginn (BEGIN <ID>) einer Konfigurationsroutine. Ist diese Routine nicht im Speicher der CT vorhan- 
den, so wird sie von der daruberliegenden CT angefordert, bzw. aus dem Speicher geladen. 

4. LOAD <ID> 65 

Fordert die KR <ID> von der daruberliegenden CT an. 
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2. BOOT <CT-ED> 

BOOT <CT-H>> kennzeichnet in welche CT die nachfolgende Boot-KR geschrieben werden soil. Nach BOOT <CT- 
E)> folgt kein BEGIN, die Boot-KR wird nicht durch STOP, sondern durch ein nachfolgendes BOOT <CTID> abge- 
schlossen. Ein STOP beendet den Bootvorgang. 5 

BOOT <CT-ID> darf nicht innerhalb eines Programmes auftreten. 

Boot-Vorgang 

Nach einem RESET ladt die CT des obersten Hierarchie-Levels (ROOT-CT) die Boot-KR in die CTs der unteren Hier- 10 
archien. Dazu existiert ein Sprung an eine festgelegte Adresse (BOOT-ADR) im, der ROOT-CT zugeordneten, externen 
Konfigurationsspeicher (ECR). Die ROOT-CT fuhrt diesen Sprung durch und erreicht die Boot-Sequenz. Diese ist wie 
folgt aufgebaut: 

BOOT <CT-ID0>; COMMAND; COMMAND; . . . 

BOOT <CT-ID1>; COMMAND; COMMAND; ... 15 

BOOT <CT-IDn>; COMMAND; COMMAND; . . . 
STOP; 

Wahrend des Boot- Vorganges wird zunachst die komplette Boot-KR in das CTR ab Adresse 2 der durch <CT-K)> an- 
gegebenen CT geschrieben. Die Beginnsequenz des Boot-KR (BEGIN <0>) wird nicht auf Adresse 1 geschrieben. An 20 
dessen Stelle stent WATT-FOR-BOOT, das bei einem RESET automation gesetzt wird. Erst nachdem die gesamte Boot- 
KR in das CTR geschrieben ist, und die ROOT-CT das nachste BOOT <CT-ID> erreicht hat, wird STOP an das Ende des 
Boot-KR in das CTR geschrieben und WAIT_FOR_BOOT mil BEGIN <0> uberschrieben. Die CTS beginnt mit der Ab- 
arbeitung der Boot-KR. 

25 

Laden einer Konfigurationsroutine 
Es existierem drei Gundmechanismen um eine Konfigurationsroutine, auBer der Boot-KR anzufordern: 

1. Ausfuhren eines LOAD <ID> durch die CTS 30 

2. Ausfuhren eines EXECUTE <H>> durch die CTS, wobei die KR mit der betreffenden ID nicht im CTR vorhan- 
den ist. 

3. Auftreten eines Triggers, der iiber die LUT1 auf einen <TD> ubersetzt wird, dessen zugehorige KR nicht im CTR 
vorhanden ist. 

35 

Der Ablauf in alien drei Fallen ist derselbe: 
Die ID der angeforderten KR wird der LUT2 als Adresse angegeben. Die LUT2 uberpriift, ob eine gultige Adresse im 
CTR existiert. Existiert diese nicht, d. h. <ID> zeigt in der LUT2 auf den Wert 0, wird load <ID> an die CTS gesendet. 

Die CTS fordert daraufhin die <ID> betrefFende KR bei der hierarchisch iibergeordneten CT an. Diese Anforderung 
erreicht die ubergeordnete CT in Form eines Triggers und wird entsprechend von ihr ausgewertet. 40 

Die ubergeordnete CT sendet die angeforderte KR an die anfordemde CT. Die Daten werden ab der Adresse, auf die 
der FREE-POINTER (FP) zeigt in das CTR geschrieben, wobei der FP nach jedem SchreibzugrifF um eins erhoht wird. 
Erreicht der FP die obere Grenze des CTR, wird der Garbage-Kollektor (GQ aufgerufen, um die unterste KR innerhalb 
des CTR zu entfernen und das CTR zu komprimieren. Der FP wird dabei neu gesetzt. Dieser \brgang findet so lange 
statt, bis die zu ladende KR komplett in das CTR paBt. 45 



Sprungtabelle im Konfigurationsspeicher 

Der der ROOT-CT zugeordnete Konfigurationsspeicher beinhaltet samtliche KR, die fur eine Applikation geladen 
werden miissen. Im externen Konfigurationsspeichers (ECR) befindet sich an einer festgelegten Adresse (ADR-BOOT) 50 
Sprung zu derBoot-Konfigurations-Routine. In einem weiteren festgelegten Speicherbereich (LUT-ECR) beliebiger, je- 
doch fest vorgegebener Lange die Sprunge zu den einzelnen KRs. Dabei wird die <ID> der jeweiligen KR als Adresse im 
ECR verwendet, an der die Startadresse der jeweiligen KR steht; wodurch KRs indirekt adressiert werden: 

ID — ► LUT-ECR — ► KR , 55 

Anderung der KR im Konfigurationsspeicher 

Die KR mit der ID <A> soli geandert werden. Zunachst schreibt der HOST die neue KR fur die ID <A> an eine fireie 
Speicherstelle im ECR. Die ID <A> wird zusammen mit der neuen Adresse der KR im Konfigurationsspeicher von der 60 
ubergeordneten Einheit (HOST) in ein dafur vorgesehenes Register der ROOT-CT geschrieben. Die ROOT-CT sendet an 
alle darunterliegenden CTs das Kommando REMOVE <A>. Daraufhin entfernen alle CTs beim Erreichen eines STOP 
oder wahrend IDLE-Zyklen, also sobald keine KR ausgefuhrt wird, die auf diese ID bezogene KR aus dem CTR und set- 
zen die LUT2 an Adresse <A> auf "NoAdr", das bedeutet, es existiert keine giiltiger Adresseintrag fiir ID <A> in LTJT2. 
Wird die ID <A> emeut angefordert, zwingt der fehlende Einlrag ("NoAdr") an Stelle <A> in die LUT2 jede CT die KR 65 
<A> vom ECR neu anzufordern. 
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5. REMOVE <ID> 

Ruft den GC auf, urn die Konfigurationsroutine <ID> von BEGIN <ID> bis STOP aus dem Speicher der CT zu ent- 
femen und die nachfolgenden Konfigurationsroulinen so weit vorzuschieben, dafi kein Speicherloch durch die enlfernte 
5 Konfigurationsroutine entsteht. 

6. PUSH <FORCED> <ADDRESS> <DATA> 

Schreibt die Konfigurationsdaten <DATA> an das Register <ADDRESS>. 1st <FORCED> gesetzt, werden die Daten 
10 auch geschrieben, wenn das RECX)NHG-Flag des betreffenden Zielregisters nicht gesetzt ist. 

7. MASK <SR> <TRIGGER> 

Setzt die Trigger-Maske mit <TRIGGER>, bzw. setzt sie mit <TRIGGER> zuriick, abhangig von <SR> (Set/Reset) 

15 

8. WAIT <UNMASCELD> <TRIGGER> 

Halt die Abarbeitung der Konfigurationsroutine an und wartet auf den Trigger <TRIGGER>. Ist <UNMASCELD> ge- 
setzt, wird auf das erwartete Trigger unabhangig des Zustandes der TVigger-Maske reagiert. 

20 

9. TRIGGER <TRIGGER> 

Sendet den Binarwert eines Triggers an die ubergeordnete CT. 

25 1 0. REFERENCE <TRIGGERxID> 

Schreibt in die LUT1 bei Adresse <TRIGGER> den Wert <ID>, wodurch einem Triggersignal eine bestimmte KR zu- 
geordnet wird. 

Die Befehle EXECUTE, LOAD, REMOVE, PUSH, MASK, WATT, TRIGGER, REFERENCE sind nur innerhalb der 
30 Klammer BEGIN . . . STOP gultig. AuBerhaib dieser Klammer werden die Befehle nicht ausgefuhrt. 
Der Aufbau einer Konfigurationsroutine (KR) sieht wie folgt aus: 
BEGIN <ID>; 

gultige Befehle 
35 ... 
STOP; 

Indirekte Addressierung (Referenzierung) 

40 Das Cache-Prinzip der CT ermoglicht das Zwischenspeichern einer KR in einer CT, wobei die KR von mehreren un- 

terschiedlichen tieferliegenden CTs oder CELs genutzt werden. 

Werden von den tieferliegenden Einheiten Zugriffe auf das exteme Interface des Bausteines (z. B. RAM, Peripherie) 

durchgefuhrt, ergibt sich die Notwendigkeit unterschiedliche Adressen oder Teile des extemen Interfaces zu speichem. 

Dadurch wurde sich der Inhalt der einzelnen benougten KRs grundlegend unterscheiden. Ein Caching ist nicht mehr 
45 moglich. 

Abhilfe schafft eine indirekte Referenzierung. Dazu werden spezieUe KR (im folgenden DCR genannt) verwendet, die 
die notwendigen extemen Paramter beinhalten und setzen. Eventuell werden uber Trigger andere unterschiedliche KRs 
in verschiedenen Hierarchieebenen aufgerufen. Ab Ende einer IKR wird das eigentliche KR aufrufen. Lediglich die IKR 
sind nicht cachebar, wahrend die aufgerufenen KR durchaus einheitlich und daher cachebar sind. Es ist sinnvoll, die 
50 GroBe der IKR auf das absolute Minimum zu reduzieren, namlich ausschlieBlich die extemen und unterschiedlichen Pa- 
rameter und den Aufruf der einheitlichen KR. Eine indirekte Konfigurationsroutine (IKR) ist wie folgt aufgebaut: 
BEGIN <TD>; 

xxx; gultige Befehle, wobei lediglich exteme Peripherie angesteuert werden sollte, 
55 TRTGGER <ID>; Start-, Stop- oder Lade-Anforderungen an Periphere Prozesse 

GOTO <ID>; Sprung zur einheitlichen KR STOP; 

Sonderfalle 

60 

1. WATT_FOR_BOOT 

Dieses Kommando ist nur an der ersten Adresse des CTR gultig. Wahrend des Boot-^rganges wird zunachst die 
komplette Boot-KR in das CTR geschrieben, jedoch nicht die Beginnsequenz des Boot-KR BEGIN <0>. An dessen 
65 Stelle (auf Adresse 1) steht WAIT-FOR-BOOT, das bei einem RESET automatisch gesetzt wird. Erst nachdem die ge- 
samte Boot-KR in das CTR geschrieben ist, wird WATT_FOR_B OOT mit BEGIN <0> iiberschrieben und die CTS be- 
ginnt mit der Abarbeitung der Boot-KR. 

WATT_FOR_BOOT darf nicht innerhalb eines Programmes auftreten. 
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Das FILM 0 

Ein KR besteht hauptsachlich aus dem Befehl PUSH, der neue Konfigurauonsworte an eine bestimmte Adresse 
schreibt. 1st das Schreiben eines Konfiguralionswortes nicht moglich, da das adressierte konfigurierbare Element (CEL) 
5 nicht bereit ist eine neue Konfiguration zu empfangen, wind das Konfigurationswort statt an das adressierte konfigurier- 
bare Element (CEL) in einen Speicher, im folgenden FILMO genannt, geschrieben. Die nachfolgenden Befehle werden 
normal abgearbeitet, bis erneut ein Konfigurationswort nicht geschrieben werden kann, das dann in das FILMO geschrie- 
ben wird. 

Das FILMO wird in IDLE-Zyklen und vor jedem Ausfuhren eines neuen KR komplett durchlaufen. Dabei wird, be- 
10 ginnend beim altesten Datenwort, entsprechend eines FIFOs nach dem Stand der Technik, jedes ausgelesene Wort des 

FILMOs an sein adressiertes Element zu senden; dabei muB das adressierte Element bereit sein das Konfigurationswort ' 
zu empfangen. Sofem die Datenworter von Beginn an geschrieben werden konnen (d. h. die adressierten konfigurierba- 
ren Elemente (CELs) sind bereit) wird der Eintrag aus dem FILMO nach Art eines FTFOs entfernt. Kann ein Konfigu- 
rationswort nicht geschrieben werden, wird es ubersprungen und nicht aus dem FILMO entfemt. Im Gegensatz zu einem 
15 FIFO werden die Daten nach dem iibersprungenen Konfigurationswort weiter ausgelesen. Konfigurationsworte, die nach 
einem iibersprungenen Konfigurationswort geschrieben werden konnen werden entweder je nach Implementierung des 
FILMOs 

1 . als geschrieben markiert und nicht aus dem FILMO geloscht, wobei als geschrieben markierte Konfigurations- 
20 worter bei den folgenden Durchlaufen nicht mehr gelesen werden, bzw. sofort geloscht werden, sofem kein uber- 

sprungenes Konfigurationswort mehr vor ihnen liegt; oder 

2. aus dem FILMO geloscht, wobei die Konfigurationswoiter vor und nach dem geloschten Konfigurationswort er- 
halten bleiben, dabei mussen zum Loschen die nachfolgenden Worte nach vorne (oben) oder die davorliegenden 
Worte nach hinten (unten) geschoben werden, wobei die Reihenfolge der Konfigurationsworte unbedingt beibehal- 

25 ten wird. 

Wird eine neue KR ausgefuhrt, werden die Konfigurationsworte (KW), die von der CTS nicht an die adressierten Ele- 
mente (CELs) geschrieben werden konnten, erneut an das FELMO angehangt, d. h. die KW werden an das Ende (aus Le- 
serichtung) des FILMOs geschrieben. Ist das FILMO voll, d. h. es existieren keine freien Eintrage fur Konfigurations- 
30 worte, wird die Ausfiihrung des KR gestoppt. Das FILMO wind so lange durchlaufen, bis geniigend Konfigurationsworte 
geschrieben werden konnten und entsprechend viele freie Eintrage entstanden sind, woraufhin das KR weiter abgearbei- 
tet wird. 

Das FILMO stellt einen FIFO-ahnlichen Speicher dar, der immer vom altesten Eintrag an linear durchlaufen wird, im 
Gegensatz zu einem FIFO werden jedoch Eintrage ubersprungen (First In Linear Multiple Out) 

35 

Die Funktion der Konfigurationstabellen-Statemachine (CTS) 

Die Konfigurationstabellen-Statemachine (CTS) ubernimmt die Steuerung der CT. Dabei fuhrt sie die Befehle der KR 
aus und reagiert auf eingehende Trigger. Sie ubernimmt die Verwaltung des FILMOs, i.b. liest sie in IDLE-Zyklen und 
40 vor dem Ausfuhren einer KR das FILMO aus. 

Sie reagiert auf die von der LUT-Struktur generierten Signalen illegal <ID> (Illegal Trigger, siehe Fig. 1, 0102) und 
load <ID>. load <ID> wird generiert, wenn ein Cache-Miss in LUT2 vorliegt (0105), oder die durch ID referenzierte KR/ 
IKR als geloscht markiert wurde (0107) Sie reagiert auf die Steuersignale der ubergeordneten CT. Ein Implementations- 
beispiel fur die Verarbeitung der Befehle ist in den Fig. 2 bis 7 dargestellt. 

45 

Steuersignale an ubergeordnete CTs 

illegal <TD> (0102) 
load<ID> (0105/0107) 
50 trigger <trigger> (0108) 

Steuersignale von ubergeordneten CTs 

remove <ID> (siehe Fig. 15, 1513) 
55 write_to_FP <data> (siehe Fig. 2, 0205). 

Die Funktion des Garbage-KoUektors (GC) 

Der CTR unterliegt zwei Problemen: 

1 . Verweist ein LOAD- oder EXECUTE-Befehls, bzw. ein Trigger, auf eine ID, deren KR nicht im CTR vorhanden 
ist, muB die KR nachgeladen werden. U.U. ist jedoch nicht geniigend Platz im CTR vorhanden urn die angeforderte 
KR zu laden. 

2. Beim Auftreten eines REMOVE <ID> ist die entsprechende KR aus dem CTR zu entfemen. Dabei entsteht, so- 
fem sich dike KR nicht am Ende des CTR bcfindet eine Liicke. Beim Laden einer neuen KR wird die Lucke u. U. 
nicht wieder ganz aufgefullt oder die Lucke ist zu klein fur die neue KR. Dies fuhrt zu einer Fragmentierung des 
CTR. Die Aufgabe des Garbage-Kollektor ist es, KR aus dem CTR zu entfemen, urn Platz fur neue Eintrage zu 
schaffen UND nach Entfemen der Eintrage den CTR so umzuorganisieren, daB alle verbleibenden KR als geschlos- 
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sener Block hintereinander im Speicher liegen und die freigewordenen Speicherbldcke als ein geschlossener Block 
an einem Ende des CTR liegen. Dadurch kdnnen auf optimale Weise und ohne Veiiuste an Speicherplatz neue KR 
nachgeladen werden. 

5 

Auswerten von TYiggerimpulsen 

Jede CT besilzL einen AnschluB an mehrere zu ihrer jeweiligen Hierarchieebene gehorenden THggersignale, die zu ei- 
nem Bus zusammengefaBl sind. Eingehende Trigger werden uber eine Maske ausgewertet, d. h. nur die freigeschalteten 
Triggersignale werden weitergeleitet. Die freigeschalteten TYiggersignale werden laktsynchron in einem Sample-Regi- 10 
ster zwischengespeichert (gesampled). Ein Round-Robin-Arbiter wahlt ohne Prioritat eines der gespeicherten THggersi- 
gnale aus und wandelt das Signal in einen binaren Vektor. Das gewahlte Triggersignal wird aus den Sample-Register ge- 
loscht Der Binarvektor wird an eine erste Lookup-Tabelle (LUT1) weitergeleitet, die den Binarvektor in die Identifika- 
tionsnummer (ID) der aufzurufenden Konfigurationsroutine (KR) iibersetzt. Die ID wird in einer zweiten Lookup-TV 
belle (LUT2) in die Adresse der KR im CT-Speicher (CTR) iibersetzt. Die CT-Statemachine (CTS) setzt ihren Pro- 15 
gramm-Pointer (PP) auf diese Adresse und beginnt mit der Ausfuhrung der KR. Vbraussetzung ist, daB jeder uber die 
Maske freigeschaltete Trigger einen entsprechenden Eintrag in LUT1 besitzt Fehlt dieser, wird ein Fehlerzustand an die 
CTS weitergeleitet (illegal trigger), dabei wird jede ID = "NoAdr" als nicht vorhandener Eintrag gewertet. "NoAdr" ist 
ein implementationsabhangig gewahltes Token. 

Fehlt der Eintrag in LUT2, d. h. die auf die ID bezogene KR befindet sich nicht im CTR, wird eine Ladeanforderung 20 
an die CTS gesendet (load <ID>). 

Senden von Triggerimpulsen an die Ubergeordnete CT Neben der bereits beschriebenen Schnitt stelle zu einer uberge- 
ordnerten CT zum Laden von KR existiert eine weitere Schnittstelle zum Austauschen von THggersignalen. Dabei sendet 
eineCT 

25 

1. an alle anderen CTs einen Triggervektor (BROADCAST) 

2. an die daruberliegende CT einen Triggervektor (HIGHER) 

3. an die darunterliegende CT einen Triggervektor (LOWER) 

4. an eine beliebige adressierte CT einen Triggervektor (ADDRESSED) 

30 

Wobei ein TViggervektor einen Binarwert darstellt, der auf einen Eintrag in der LUT2 der empfangenden CT referen- 
ziert. Der Mechanismus ist notwendig um beispielsweise innerhalb einer IKR eine KR in einer weiteren CT zu starten um 
beispielsweise die Peripherie oder den Speicher anzusteuern. 

Zur Weiterleitung von Triggersignalen an eine ubergeordnete CT existieren 2 Mechanismen: 

35 

1 . Der LUT1 wind ein Bit hinzugefugt, das angibt, ob der Inhalt des Speichers als KR ID oder als Binarwert fur ei- 
nen Triggerimpuls betrachtet wird, Liegt ein TViggerimpuls vor, wird der Dateninhalt von LUT1 direkt als Trigger 
an die ubergeordnete CT gesendet 

2. Mit dem Befehl TRIGGER kann der Binarwert eines Triggers angegeben werden, der direkt an die ubergeord- 
nete CT gesendet wird. 40 



Der priorisierte Round-Robin-Arbiter 

Der priorisierte Round-Robin-Arbiter (Single-Cycle-Round-Robin-Arbiter SCRR-ARB) ist taktsynchron aufgebaut, 45 
d. h. bei jeder - je nach Implementierung positiven oder negativen - Taktflanke (TF1) liefert er ein Ergebnis. Die einge- 
henden Signale (ARB-IN) durchlaufen eine Maske (ARB-MASK), die von dem Arbiter gemaB dem nachfolgend be- 
schriebenen Verfahren selbst verwaltet wird. Die Ausgangssignale der Maske werden an einen Priori tatsarbiter nach dem 
Stand der Technik geleitet. Der Arbiter liefert taktsynchron bei jeder Taktflanke (TF1) ein Ergebnis (ARB-OUT), d. h. 
den Binarwert des hochstpriorisierten Signals nach der Maske (ARB-MASK). Dem Ergebnis zugeordnet ist ein Signal 50 
(VALID), das angibt, ob der Binarwert gultig oder ungiiltig ist Abhangig von der Implementierung der Priori tatsarbiters 
ist es moglich, dafi beim Anliegen des Signals 0 und beim Anliegen keines Signals derselbe Binarwert generiert wird: In 
diesem Fall zeigt VALID an, dafi das Ergebnis ungultig ist, sofern kein Signal anliegt. Dieses Signal wird 

1 . als Ergebnis der Arbiters ausgegeben und 55 

2. auf einen Dekoder geschaltet, der die Binarwerte - wie in der folgenden Tabelle beispielsweise fur einen 3-bit 
Binarwert angeben - auskodiert (Das Kodiemngsverfahren ist gemaB dieses Prinzips auf jeden beliebigen Binar- 
wert anpaBbar): 



65 
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Binarwert 
(ARB-OUT) 


Auskodierung 
(ARB-DEC) 


Bemerkung 


111 


0111 1111 




110 


0011 1111 




101 


0001 1111 




100 


0000 1111 




Oil 


0000 0111 




010 


0000 0011 




001 


0000 0001 




000 


1111 1111 


Reset-Zustand und 

wenn Binarwert (ARB-OUT) ungdtig 



Dem Dekoder zugeordnet ist ein Register (ARB-REG), das die auskodierten Werte (ARB-DEC) des Dekoders bei der 
zu TF1 inversen Taktflanke (TF2) Ubernimmt. ARB-DEC wird auf die Maske (ARB-MASK) zuriickgekoppelt und 
schaltet die einzelnen Eingangssignale (ARB-IN) frei. 

Der funktionale Ablauf im Arbiter ist wie folgt: 

1. Nach einem RESET sind alle ARB-IN uber ARB-MASK freigeschaltet, da ARB-DEC alle Signale auf "Frei- 
gabe" stellt. 

2. Das hochst priorisierte gesetzte ARB-IN (beispielsweise besitzt in der obigen Tabelle das Signal 7 (binar 111) 
die hochste Priori tat und 0 (binar 000) die niederste Priori tat) wird als Binarwert ausgegeben. 

3. tfber ARB-DEC wird das Signal gesperrt, sowie alle weiteren Eingange die evtl. noch hoher priorisiert waren, 
aber nicht gesetzt sind. 

4. Die folgenden Schritte 5 und 6 wiederholen sich so lange, bis das Signal 0 (binar 000) erreicht ist, oder kein Si- 
gnal hinter ARB-MASK mehr anliegt. Dann schaltet ARB-DEC (siehe Auskodierungstabelle) wieder alle Signale 
durch ARB-MASK uber ARB-DEC frei und der Ablauf beginnt bei Schritt 2. 

5. Das nunmehr hochst priorisierte gesetzte ARB-IN wird als Binarwert ausgegeben. 

6. Uber ARB-DEC wird das Signal gesperrt, sowie alle weiteren Eingange die evtl. noch hoher priorisiert waren, 
aber nicht gesetzt sind. (Weiter mit Schritt 4). 

Dadurch wird erreicht, daB alle Eingangssignale gleichberechtigt behandelt werden und bei jedem Taktzyklus eines 
der Eingangssignale (ARB-IN) binar aus kodiert und ausgegeben (ARB-OUT) wird. 

ARB-REG kann mit einem Enable-Eingang (EN) versehen werden, der eine Anderung des Registerinhaltes nur bei 
TF2 zulafit, wenn ein entsprechendes Signal anliegt. Dadurch wird nicht bei jedem Takt ein Binarvektor ausgegeben, 
sondem abhangig von einer Freischaltung durch EN und TF2. Der Eingang wird zur Synchronisation notwendig, wenn 
die nachgeordnete Schaltung die Verarbeitung nicht in einem Taktzyklus diirchfuhren kann, sondem mehrere Zyklen be- 
notigt und erst dann den nachsten Binarvektor akzeptiert. 

Figuren 

Die nachfolgend beschriebenen Figuren verdeutlichen anhand eines Implementationsbeispiels die Verwaltung von 
Konfigurationsdaten nach dem vorgestellten Verfahren: 
Fig. 1 Verfahren der Adressgenerierung innerhalb der Lookup-Tabellen 
Fig. 2-7 Abarbeitung der Befehle und Funktion der Statemachinen 
Fig. 8 Aufbau des SCRR-ARB 
Fig. 9 Aufbau der LUT1 & LUT2 
Fig. 10 Aufbau der Pointerarithmetik und des CTR 
Fig. 11 Aufbau eines FELMO 
Fig. 12a Hierarchische Anordnung der CIs 
Fig. 12b Senden eines Triggers zwischen den CTs 
Fig. 12c, d Methoden zum Senden eines 
Fig. 13 Aufruf einer KR durch mehrere DCR 
Fig. 14 Aufbau der LUT1 einer ROOT-CT 
Fig. 15 Aufbau der HOST-Steuerung einer ROOT-CT 
Fig. 16 Verdeutlichung des LUT und ECR Konzeptes 

Fig. 17 Abiaufsteuerung einer CT mittlerer Hierarchieebene, bzw. einer ROOT-CT 
Fig. 18 Deadlockproblematik bei der Konfiguration eines 2-dimensionalen Arrays 
Fig. 1 9 Verdeutlichung des FELMO-Konzeptes 
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Beschreibung der Figuren 

Fig. 1 zeigt den Ablauf der CTR-Adressgenerierung innerhalb einer CT. Dabei wird ein eingehender binarer Trigger- 
vektor (0101) in der LUT1 auf eine gultige KR oder IKR ID ubersetzt. Existiert keine giiltige ID, wird ein Signal "Illegal 
Trigger" generiert (0102), das anzeigt, daB der Trigger nicht in LUT1 bekannt ist. Das Signal kann als Fehlermeldung an 5 
die uberge ordnet e CT weitergeleitet oder ignoriert werden. Die Obersetzung von Trigger- nach "ID" wird mittels des 
Befehls "REFERENCE" in die LUT1 eingelragen. 

Eine gultige ID (0103) wird an die LUT2 weitergeleitet. IDs die innerhalb von Befehlen, also durch einen Operanden, 
angegeben sind (0104), treffen direkt auf die LUT2. Die LUT2 ubersetzt eine eingehende ID in die Adresse der KR/IKR 
innerhalb des CTR. Ist die KR/IKR nicht im CTR gespeichert (es liegt im Cache nicht vor), wird das Signal "Miss" ge- io 
neriert (0105). Ist die iibersetzte Adresse der KR/IKR mit dem Token "NoAdr" markiert, wird mit "NoEntry" (0107) an- 
gezeigt, daB die Adresse geloscht ist. "Miss" und "NoEntry" zeigen an, daB eine Ubersetzung auf eine CTR-interne 
Adresse nicht moglich ist. Auf Grundlage dieses Signals ladt die LOAD-Statemachine die KR/IKR mit der entsprechen- 
den ID von einer daruberliegenden CT nach. Sofern eine gultige Adresse vorhanden ist, wird diese an die Pointerarith- 
metik des Adressgenerators weitergeleitet (0106). In LUT1 wird ein eingehender binarer Triggervektor entweder in eine 15 
ID oder einen weiteren Triggervektor ubersetzt, wobei in diesem Fall der Triggervektor ausgegeben wird (0108). 

In Fig. 2 ist der Ablauf beim Laden einer KR/EKR dargestellt. Zunachst wird die ID (0201) der zu ladenden KR/IKR 
an die dariiberliegende CT gesendet. Daraufhin wird in die LUT2 an der Stelle des Eintrages fur die angeforderte ID der 
Wert des FreePointers (FP) eingelragen. FP zeigt auf den Eintrag hinter dem Ietzten fur eine KR/IKR genutzen Eintrag 
im CTR. Dies ist der erste Eintrag, auf den die zu ladende KR/EKR gespeichert wird. 20 

Die Statemachine wartet auf ein Datenwort von der driiberliegenden CT. Sobald das Wort verfugbar ist, wird es an die 
durch FP referenzierte Stelle geschrieben. FP wird inkrernentiert. Zeigt FP auf einen Eintrag hinter dem Ende des CTR 
wird der erste Eintrag im CTR entfernt um Platz zu schaffen (0202); dabei wird FP aktualisiert. 

Ist das von der daruberliegenen CT gesendete Datenwort "STOP", wird der Ladevorgang abgebrochen (0203), anson- 
sten mit dem Warten auf ein neues Datenwort fortgesetzt (0204). 25 

In Fig. 3a ist der "MASK"-Befehl dargestellt. Der Operand des Befehls wird in das MASK-Register geschrieben. Das 
MASK-Register befindet sich am Eingang der Triggersignale vor LUT1 und maskiert ungiiltige Trigger aus. 

In Fig. 3b wird durch den Befehl "TRIGGER" der Operand des Befehls als Triggervektor zu den anderen CTs abge- 
sendet. 

In Fig. 3c wird durch den Befehl "REFERENCE" die Ubersetzung eines Triggers zu der entsprechenden KR/IKR ID 30 
in die LUT1 geschrieben. 

In Fig. 4a wir der Befehl "WAIT" dargestellt. Der Operand des Befehls wird in das WAITMASK-Register geschrie- 
ben. AUe Trigger, bis auf den/die Erwarteten und daher in WAITMASK freigeschalteten werden ignoriert. Erst nach Auf- 
treten des Triggers wird zum ProgrammfluB zuruckgekehrt. 

In Fig. 4b ist der "PUSH"-Befehl abgebildet. Das Konfigurationswort wird zum adressierten konfigurierbaren Element 35 
(CEL) gesendet. Akzeptiert das CEL das Konfigurationswort nicht; da das CEL sich beispielsweise im Zustand "nicht 
konfigurierbar", (vgl. DE 197 04 728.9) befindet; wird das Konfigurationswort in den FILMO geschrieben (0401). 

Fig. 5 zeigt den Ablauf eines "REMOVE"-Befehles. Es gibt zwei Aufrufvarianten: 

1 . Die erste im CTR liegende KR/IKR wird aus dem CTR entfemt. Dem GarbagePointer (GP) wird die Adresse 0 40 
des CTR zugewiesen (0501). 

2. Eine spezifisch durch ihre ID angegebene KR/IKR wird aus dem CTR entfemt. Dem GarbagePointer (GP) wird 
die erste Adresse des zu entfernenden KR/EKR im CTR zugewiesen (0502). 

Der MovePointer wird mit dem Wert von GP geladen. GP und MP referenzieren auf einen "BEGIN <ID>"-Befehl im 45 
CTR, auch wenn die erste KR/IKR aus dem CTR entfernt werden soli. Die betreffende ID wird in LUT2 als unguTtig 
markiert. MP wird so lange inkrernentiert, bis das "BEGIN <ID>" des nachsten im Speicher liegenden KR/IKR erreicht 
wird (0503), ODER MP gleich dem FreePointer (FP) ist, das bedeutet, dafi die zu entfemende KR/IKR die letzte im CTR 
ist (0504). 

50 

- In diesem Fall wird FP mit dem Wert von GP geladen, wodurch die durch die zu loschende KR/IKR belegten 
Speicherstellen als frei markiert werden; und die Funktion "REMOVE" ist beendet (0505). 

- Andernfalls ("BEGIN <ID>" wird erreicht (0506)) werden die durch MP referenzierten Daten an die durch GP 
referenzierte Speichers telle kopiert. MP und GP werden inkremetiert Dieser Ablauf findet so lange stall, bis MP das 
Ende von CTR oder die Position von FP erreicht hat (0507). Wird wahrend des Ablaufes durch MP eine Speicher- 55 
stelle referenziert, in der "BEGIN <ID>" stent, wird der Eintrag fur die entsprechende ID in LUT2 mit MP uber- 
schrieben (0508), damit bei einem Lookup die richtige Speicherstelle ausgegeben wird. 

Fig. 6 zeigt das Ablaufdiagram des FILMOs. Ein FILMO beinhaltet drei Pointer 

60 

1 . WriteP: Der Schreibzeiger des FILMO-RAM 

2. ReadP: Der Lesezeiger des FELMO-RAM 

3. FullP: Der Zustandszeiger, der den "Fullstand" des FILMO-RAMs reprasentiert und einen Unterlauf, bzw. Uber- 
lauf verhindert. 

65 

Ein ein-Bit Register "BeginF" zeigl an, ob sich der aktuelle Lesezugriff am Anfang des FILMO-RAMs befindet 
(TRUE), d. h. keine nicht geloschten Eintrage befinden sich zwischen dem Lesezeiger und dem Beginn des FILMO- 
RAMs; oder sich der Lesezeiger in der Mitte des FILMORAMS befindet (FALSE), also benutzte Eintrage zwischen 
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dem Lesezeiger und dem Beginn des FTLMO-RAMS liegen. 

Weiterhin exislieren zwei Register zum Speichern der Zustande des ReadP und FullP. Es ist notwendig beim Auftreten 
des ersten ungeldschten Eintrages die beiden Register zu sichern, da bei einem spater stattfindenden Lesezugriff an der 
Stelle dieses Eintrages mit dem Auslesen begonnen werden muB. Andererseits miissen jedoch ReadP und FullP wahrend 
5 des aktuellen Lesevorganges weiterhin modifiziert werden, urn die nachsten Leseadressen zu erhalten, bzw. das Ende des 
FILMORAMs festzustellen. Durch den Aufbau des FTLMOs als FIFO-ahnliche Struktur- als sogenannten Ringspei- 
cher - kann Beginn und Ende des Speichers nicht anhand einer Adresse 0 oder eine Maximal adresse festgelegt werden. 

Aus dem Grundzustand fuhren zwei Ablaufpfade: 

10 l.Lesepfad(0601) 

FullP und ReadP werden in die Register gesichert. 
Die Abarbeitungsschleife beginnt: 
BeginF ist TRUE. 

15 Ist FullP gleich 0, werden ReadP und FullP aus ihren Registern zuriickgelesen (0602) und die Statemachine springt in 
den Grundzustand zuruck. 

Ansonsten (0603) wird getestet, ob der Eintrag im FILMO, auf den ReadP zeigt gleich "NOP" ist, d. h. es handelt sich 
urn einen als geloscht markierten Eintrag in der Mitte des FILMOs. Ist dies nicht der Fall (0604) wird versucht den Ein- 
trag in das konfigurierbare Element (GEL) zu schreiben. Gelingt dies nicht (REJECT, vgl. DE 197 04 728.9, 0605), da 
20 GEL nicht umkonfigurierbar ist, wird BeginF auf FALSE gesetzt, FullP dekrementiert und ReadP inkrementiert. Die Sta- 
temachine springt an den Beginn der Abarbeitungsschleife (0606). Gelingt das Schreiben des Eintrages an das GEL 
(0607), oder der Eintrag ist ein NOP, wird BeginF gestestet: 

BeginF = TRUE (0608): Es liegen keine ungeldschten Eintrage vor diesem. FullP wird inkrementiert, ReadP wird in 
dem zugeordneten Register gesichert, urn den neuen Anfang des FILMOs festzuhalten. FullP wird gesichert urn die ak- 
25 tuelle Datenmenge festzuhalten; ReadP wird inkrementierL 

BeginF == FALSE (0609): FullP wird inkrementiert und der aktuelle Eintrag im FILMO-RAM mit NOP uberschrieben, 
d. h. der Eintrag wird geloscht. ReadP wird inkrementiert. In beiden Fallen springt die Statemachine an den Beginn der 
Abarbeitungsschleife. 

30 2. Schreibpfad (0610) 

Es wird getestet, ob der FILMO-RAM voll ist, indem FullP auf den maximalen Wert uberpruft wird. Ist dies der Fall 
(0611), wird in den Lesepfad gesprungen um Platz zu schaffen. 
Ansonsten wird das Datenwort in den FTLMO-RAM geschrieben und WriteP und FullP inkrementiert. 
35 Fig. 7 zeigt den Ablauf in der Hauptstatemachine. Der Grundzustand (IDLE) wird verlassen, sobald ein 

1 . REMOVE-Kommando von der dariiberliegenden GT auftritt (0701): 

Der REMOVE-Befehl wird ausgefuhrt und die Statemachine kehrt nach IDLE zuruck. 

2. Ein Triggersignal zur Generierung eines Triggers zwischeri den Cft auftritt (0702): 

40 Der Trigger wird ausgegeben. Die Statemachine springt in den "STOP M -Befehl und danach nach IDLE zuruck. 

3. Ein Triggersignal zur Ausfiihrung eines KR/EKR <ID> auftritt (0703): 

Der ProgramPointer (PP) wird mit der durch LUT2 generierten Adresse geladen. Ist die Adresse ungultig, d. h. kein 
Eintrag fur das zu ladende KR/KR vorhanden, wird dieses geladen (0704) und PP neu gesetzt. 

45 Die Ausruhrungsschleife beginnt: 

PP wird inkrementiert (beim ersten Schleifendurchlauf wird dadurch der BEGIN <ID>-Befehl ubersprungen), das Auf- 
treten weiterer Trigger wird unterbunden, REGONFigur (vgl. DE 197 04 728.9) wird gespent. Die Befehle werden aus- 
gefuhrt und zum Beginn der Ausruhrungsschleife gesprungen (0707). 

Der Befehl "STOP" wird gesondert ausgefuhrt (0705). Die Trigger und REGONFIG (vgl. DE 197 04 728.9) werden 

. 50 wieder freigeschaltet und die Statemachine springt nach IDLE. Der Befehl "EXECUTE" wird ebenfalls gesondert aus- 
gefuhrt (0706). Die in EXECUTE <ID> angegebene TD wird in das ID-REG geschrieben. PP wird neu geladen und die 
durch ID angegebene KR/EKR ausgefuhrt (0708). 

Nach einem Reset der CT wird die Grundkonfiguration in das CTR geladen und direkt in die Ausfiihrung der Grund- 
konfiguration gesprungen (0709) 

55 Fig. 8 zeigt den Aufbau eines SGRR-ARB. Die zu arbitrierenden Signale gelangen iiber Dataln auf eine Maske (0801), 
die gemaB der bekannten Tabelle einen zusammenhangenden Teil der Signale durchschaltet, bzw. spent. Ein gewohnli- 
cher Prioritatsarbiter (0802) nach dem Stand der Technik arbitriert ein Signal aus der Menge der Durchgeschalteten und 
lieferte dessen Binarvektor (BinaryOut) zusammen mit einer gultig/unguTtig-Kennung (ValidOut) (ebenfalls gemaB dem 
Stand der Technik) als Ausgang des SGRR-ARB. 

60 Dieses Signal wird gemaB der bekannten Tabelle dekodiert (0803) und auf ein Register zur Taktsynchronisierung 
(0804) gefuhrt. Ober dieses Register wird die Dataln Maske geschaltet. Dabei wird das Register entweder durch einen 
Takt oder ein Next-Signal (Enable EN), das den nachsten giiltigen Binarvektor abfragt gesteuert Bei einem Reset oder 
wenn die Kennung (ValidOut) ungultig anzeigt wird das Register so geschaltet, daB die Dataln Maske alle Signale durch- 
schaltet. 

65 Der Aufbau der Maske ist in 0805 dargestellt. * 
In Fig. 9 ist die LUT-Struktur abgebildet. Der Binarvektor (Binaryln) des arbitrierten Triggers wird auf den Adress- 
eingang der LUT1 (0901) gefuhrt. 

LUT1 ubersetzt den Binarvektor entweder in einen gultigen Trigger um diesen an eine andere GT weiterzuleiten oder 
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eine gultige ID. Beidc werden iiber 0910 ausgegeben. 0911 zeigt an, ob es sich urn einen Trigger oder eine ID handelt. 1st 
uber den Befehl "REFERENCE" keine Ubersetzung des eingehenden Binarvektors in LUT1 eingeiragen, wird - mittels 
eines Biteintrages oder eines Vergleichers auf ein bestimmtes Token (z. B. "VOID") - das Signal "Illegal Trigger" 0914 
generiert. 

Ein Trigger wird iiber 0912 an externe CTs gefuhrt, IDs werden uber den Multiplexer (0902) weiterverarbeitet. 0902 5 
schaltet entweder der Datenausgang von LUT1, der eine gultige ID angibt, oder das ID-Register (0903) der CT auf den 
Adresseingang der LUT2 (0904). 0904 besitzt eine Cacheahnliche Struktur, d. h. der niederwertige Teil (0906) des Da- 
tenausgangs von 0902 wird auf den Adresseingang von 0904 geschaltet, wahrend der hoherweruge Teil (0907) auf den 
Dateneingang von 0904 geschaltet wird. Der 0907 gehorende Datenausgang wird uber einen Komparator (0905) mit 
0907 verglichen. Der Vorteil dieses Verfahrens ist, daB 0904 nicht die Tiefe zur Obersetzung aller IDs aufweisen muB, 10 
sondern erheblich kleiner ausfallen kann. Ahnlich eines gewohnbchen Caches wird lediglich ein Teil der IDs ubersetzt, 
wobei in der LUT2 anhand 0907 festgestellt werden kann, ob die selektierte ID der von LUT1 angegebenen entspricht. 
Dies entspricht einem Cache/TAG- Verfahren nach dem Stand der Technik. 

Einem zweiten Dateneingang von 0904 ist ein Multiplexer 0908 zugeordnet, der je nach Operation den FreePointer 
(FP, Operation LOAD), den GarbagePointer (GP, Operation REMOVE) oder eine Tnvalid-Kennung/Token (NoAdr, 15 
Operation REMOVE) zur Speicherung an LUT2 liefert. Die beiden Pointer referenzieren auf Speicherstellen im CTR, 
"NoAdr" gibt an, daB kein Eintrag zu der passenden ID exisUert, der Eintrag geloscht wurde. Dies wird am Datenausgang 
festgestellt, indem uber den Vergleicher 0909 die Daten auf das Token "NoAdr" verglichen werden. 

An die Statemachine wird weitergeleitet: 

20 

- Das Auftreten eines Binarvektors wird uber "Validln" (vgl. Fig. 8). 

- Die Angabe ob es sich bei der tJbersetzung in LUT1 um einen Trigger oder eine ID handelt (0911, "Trigger/ID 
Out"). Trigger werden uber 0912 an andere CTs weitergeleitet, IDs werden in der eigenen CT abgearbeitet und an 
die LUT2 weitergeleitet. 

- Das Ergebnis von 0905, das angibt, ob die entsprechende ID in 0904 gespeichert ist ("Hit/Miss Out"). 25 

- Das Ergebnis von 0909, das angibt, ob die entsprechende ID auf eine gultige Adresse im CTR zeigt ("NoEntry 
Out") Die von 0904 generierte Adresse wird an das CTR weitergeleitet ("CTR Address OutW). 

Die LUT1 wird iiber den Befehl "REFERENCE" mit der Ubersetzung des eingehenden Binarvektors auf einen Trigger 
oder ID geladen. Die Operanden des Befehls werden iiber den Bus 0913 an die LUT1 gefuhrt. Uber denselben Bus wird 30 
das ID-Register (0909) geladen. 

Fig. 10 zeigt die Pointerarithmetik des GarbagePointer (PG), ProgramPointer (PP), MovePointer (MP) und FreePoin- 
ter (FP). Jeder Pointer besteht aus einem getrennt ansteuerbaren ladbaren up/down-Zahler. Jeder Zahler kann - sofern 
notwendig - mit dem Wert jedes anderen Zahlers geladen werden; ebenso wie mit der Ausgabe von LUT2 (1007). 

Uber Vergleicher wird festgestellt ob 35 

1. PPgleichMP 

2. MPgleichFP 

3. FP gleich der maximalen Position im CTR 

40 

ist. Die Ergebnisse werden zur Steuerung der Statemachines verwendet. 

Ober einen Multiplexer (1001) wird einer der Pointer zum Adresseingang des CTR geleitet. Die Daten gelangen iiber 
einen Multiplexer (1002) entweder von der ubergeordneten CT (1005) oder aus einem Register (1003) an das CTR. Zur 
Statemachine und zum FELMO (1006) werden uber einen Multiplexer (1004) entweder die Daten von der ubergeordne- 
ten CT oder des CTR weitergeleitet. Dabei wird beim Auftreten eines REMOVE-Befehls von der ubergeordneten CT der 45 
direkt uber 1004 an die Statemachine geleitet, wahrend ansonsten die Befehle aus dem CTR an die Statemachine gefuhrt 
werden. Das Register 1003 dient zur Speicherung und Ruckkopplung von Befehlen auf den CTR Eingang, die wahrend 
eines Durchlaufs des Garbage-Kollektors von einer Adresse an eine andere geschoben werden. 

Der Aufbau eines FILMOs ist in Fig. 1 1 dargestellt. Die Daten gelangen von dem CTR (1101) in das FTLMO und wer- 
den entwerder uber den Multiplexer (1102) in das FILMO-RAM (1103) geschrieben oder iiber den Multiplexer (1104) an 50 
die konfigruierbaren Elemente (1116) gesendet Werden Daten in 1103 geloscht, wird uber 1102 eine M NOP"-Token nach 
1103 geschrieben. Uber den Vergleicher (1105) am Datenausgang wird das "NOP"-Token erkannt und ein Schreiben zu 
den konfigurierbaren Elementen verhindert. tiber den Multiplexer 1106 wird entweder der Schreibzeiger WriteP (1107) 
oder der Lesezeiger (1108) an den Adresseingang von 1103 gefuhrt. In dem Register 1109 wird der Lesezeiger gesichert 
um ein Riicksetzen (siehe Fig. 6) zu ermoglichen. 55 

Der Fullstandszahler Full (1110) von 1103 wird gemaB Fig. 6 in dem Register 1111 zum Riicksetzen gespeichert. Zwei 
Vergleicher testen, ob 1103 leer (1112) oder voll (1113) ist. tiber den Multiplexer 1115 wird selektiert, ob die Steuersi- 
gnale der Statemachine (von 1101) oder des FILMOs an 1116 gesendet wird. 

Fig. 12a zeigt den hierarchischen Aufbau der CTs. Alle CTs beziehen ihre Daten aus der ROOT-CT (1201) und dem 
ihr zugeordneten ECR (1204). Fur jede Implementierungsebene in einem Baustein existiert eine oder mehrere CTs. Jede 60 
CT ist fur die Verwaltung ihrer Ebene und der darunterliegenden CTs zustandig. Es ist nicht notwendig, daB alle Aste das 
Baumes gleich tief sind. Beispielsweise konnen weniger Ebenen zur Steuerung der Peripherie (1202) eines Bausteines 
existieren als zur Steuerung der Arbeitseinheiten (1203) Der Datentransfer erfolgt baumartig. Jede CT arbeitet als Cache 
fur alle unter ihr liegenden CTs. 

Fig. 1 2b zeigt den TriggerfluB zwischen den Cft. Wahrend der DatenfluB baumartig verlauft, ist der TViggerfluB nicht 65 
festgelegt. Jede CT kann an jede andere einen Trigger senden. Fur gewohnlich findet ein Triggeraustausch nur von den 
Blattem (1203) in Richtung der ROOT-CT (1201) statL Unter Umstanden kann der Transfer jedoch auch in die entge- 
gengesetzte Richtung verlaufen. 
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In Fig. 12c ist ein Triggervektor Broadcast dargestellt, wobei 1205 einen Triggervektor an alle CIs sendet. Fig. 12d 
zeigt einen HIGHER-Triggervektor, den 1206 an die Uber ihr liegende CT sendet. 1207 sendet einen LOWER-Trigger- 
vektor an alle unter ihr liegenden CTs. 1208 ubertragt einen direkt adressierten (ADDRESSED>1riggervektor an eine 
bestimmte CT, die nicht direkt mit 1207 verbunden ist. 
5 In Fig. 1 3 fordern zwei unabhangige IKR n und m eine gemeinsame, in der dariiberliegenden CT gecachte KRx an. Es 
ist angedeutet, dafi diese KR von dem gesamten Ast gecachet wird und auch in einem Nachbarast (1301) uber eine ge- 
meinsame CT verfugbar ist. 

Fig. 14 zeigt ein gegeniiber Fig. 9 modifiziertes LUT-System, das in ROOT-CTs und CIs mitlierer Hierarchieebenen 
verwendel wird. Der grundlegende Unterschied zu den bislang beschriebenen CIs ist, daB anstatt einzelner Triggersi- 

10 gnale ID- und/oder Trigger- Vektoren von der CT venvaltet werden mussen. Jedem Vektor ist dabei ein Handshake-Si- 
gnal (RDY, ygl. DE 197 04 728.9) zur Anzeige der GUltigkeit des Vektors zugeordnet, die an einen Arbiter (1401) gelei- 
tet werden. Uber die Multiplexer (1402, 1403) wird entweder einer der Triggervektoren (1404) oder einer der ID- Vekto- 
ren (1405) ausgewahlt. Triggervektoren gelangen direkt auf den Adresseingang der LUT1 (1406), die ansonsten gemaB 
Fig. 9 beschaltet ist. Das ID-Register (1407) ist ebenfalls gemaB Fig. 9 beschalteL Im Gegensatz zu Fig. 9 besitzt der 

15 Multiplexer 1408 drei Eingange (vgl. 0902). Der Multiplexer wird dabei auBer von der Statemachine zusatzlich von dem 
Arbiter 1401 angesteuert. Ober den zusatzlichen Eingang werden ID- Vektoren iiber 1403 direkt an die LUT2 weiterge- 
leitet. Dazu dient der Bus 1409. "Trigger/ID Out" wird gemaB Fig. 9 generiert. Ein "Validln" Signal, das gemaB Fig. 9 
auf ein "Valid Out" weitergeleitet wird existiert nicht. Statt dessen wird je nach Arbitrierung durch 1401 ein "Valid Trig- 
ger Out" fur Triggervektoren und ein "Valid ID Out" fur ID- Vektoren generiert, urn die Statemachine anzuweisen, wie 

20 die Verarbeitung stattzufinden hat. 

Der Bus 1409 wird iiber 1410 an eine weitere Einheit geleitet, die nur in der ROOT-CT existiert und in Fig. 15 be- 
schrieben ist. 

Eine ROOT-CT benotigt zusatzlich zu den normalen CT-Funktionen ein Interface zu dem externen Konfigurations- 
speicher (ECR), sowie den erforderlichen Adressgenerator und Einheiten zum Verwalten der Zugriffe auf den ECR. 

25 Eine gewohnliche CT ubersetzt in LUT1 eingehende Triggervektoren auf einen ID und in LUT2 das ID auf eine Spei- 
cherstelle im CTR (siehe Fig. 16a). Eine ROOT-CT ubersetzt bei ZugrifTen auf das ECR eine ID innerhalb des ECR auf 
eine Adresse im ECR, an der das durch TD referenziert KR/IKR beginnt. Dazu ist ein Speicherbereich im ECR festge- 
legt, dessen GrbBe der moglichen Anzahl an IDs entspricht (ist beispielsweise eine ID KVbit breit, ergibt das 2 10 = 1024 
mogliche IDs, also werden 1024 Eintrage im ECR reserviert). In den folgenden Beispielen berlndet sich dieser Speicher- 

30 bereich am unteren Ende des ECRs und wird LUT-ECR genannt, urn die Ahnlichkeit zur LUT2 zu unterstreichen. Die 
t)bersetzung eines Triggers auf eine ID findet dabei gemaB den bereits bekannten CTs in der LUT1 statt (1601). Zum bes- 
seren Verstandnis verdeutlicht Fig. 16b den Zugriff auf das ECR. 

Eine ID gelangt in Fig. 15 uber den Bus 1410 auf Fig. 14 an den Multiplexer 1501. Uber 1501 wird die ID in den lad- 
baren Zahler 1502 geschrieben. Der Ausgang von 1502 fuhrt uber einen Multiplexer 1503 an den Adressbus (1504) des 

35 ECR. Uber den Datenbus 1505 gelangt die Obersetzung der ED auf eine Speicheradresse uber einen Multiplexer/Demul- 
tiplexer (1506) an 1501, der 1502 mit der Speicheradresse ladt. Daraufhin werden uber die Statemachine LOAD-ECR 
(siehe Fig. 17) die Datenworter der entsprechenden KR/IKR aus dem ECR gelesen und in das CTR geschrieben, wobei 
1502 nach jedem Lesevorgang erhoht wird; so lange, bis der Befehl "STOP" gelesen wurde. 
Uber das Interface 1507 schreibt der ubergeordnete HOST uber 1503/1506 die KR/IKR in das ECR. Dabei wird uber 

40 die Statemachine (CTS) arbitriert, ob der HOST oder die ROOT-CT Zugriff auf das ECR hat. 

Nach einem Reset des Bausteines muB eine Grundkonfiguration (BOOT-KR) geladen werden. Dazu wird eine feste 
Speicheradresse (BOOT-ADR) eingefuhrt, die auf die erste Speicherstelle der BOOT-KR zeigt. Als BOOT-ADR wird 
die Speicherstelle Oh empfohlen, sofern die TDs bei 1 beginnen, andernfalls kann 2 1D oder irgend eine andere Speicher- 
stelle verwendet werden. In dem Ausfuhrungsbeispiel wird TP verwendet. 

45 Die ROOT-CT fuhrt zum Laden der BOOT-KR an der Stelle BOOT-ADR einen Lookup durch, sofern eine BOOT-KR 
geladen ist. Die ROOT-CT schreibt die Daten nach 1502 um von dort die BOOT-KR bis zum Auftreten eines "STOP" 
Befehls zu laden. 

Eine Oberwachungseinheit innerhalb der ROOT-CT ubemimmt die Synchronisation des HOST mit dem Bau stein. 
Dies geschieht folgendermafien: 
50 Die Adressen kleine 2 ID werden durch 1508 uberwacht, d. h. bei Zugriffen auf diese Adressen durch den HOST wird ein 
Signal (ACC-TD) an die Statemachine (CTS) gesendet. Ebenfalls wird BOOT-ADR iiber 1509 uberwacht und sendet ein 
Signal ACC-BOOT an die Statemachine(CTS). 

Die Statemachine (CTS) reagiert wie folgt: 

55 - Schreibt HOST auf die BOOT-ADR, bewirkt dies das Laden der BOOT-KR. 

- Schreibt HOST das Datenwort 0 (1512) auf die BOOT-ADR, wird dies uber den Komparator 1510 festgestellt 
und bewirkt das Anhalten des Bausteines. 

- schreibt der HOST auf eine Adresse kleiner 2 ID wird die Adresse in das REMOVE-Register (1511) geladen. Da 
die Adresse der ID entspricht (siehe ECR-LUT) stent die ID der geanderten KR/IKR in 15U.\An alle CTs wird der 

60 Befehl REMOVE <ID> zur sofortigen Ausfuhrung gesendet (1513). Die CTs loschen daraufhin die KR/IKR der 

entsprechenden ID aus ihrem CTR, bzw. LUT2. Bei einem nachfolgenden Aufruf der KR/IKR mussen die CIs 
zwangslaufig die neue KR/IKR aus dem ECR laden. 

Fig. 17 zeigt den Ablauf in einer ROOT-CT bei Laden einer KR/IKR aus dem ECR. Befindet sich eine ID nicht im in- 
65 ternen CTR (vgl. Fig. 1, 1701) wird die ID in den Zahler 1502 geschrieben (1703). Ein Zugriff auf das ECR mit der 
Adresse in 1502 liefert die Basisadresse der KR/EKR. Diese wird in 1502 geschrieben (1704). Ein LOAD gemaB Fig. 2 
findet statt (1702). Dabei werden die Daten statt von einer tjbergeordneten CT aus dem ECR gelesen (1705) und nicht 
nur in das eigene CTR geschrieben, sondem, an die untergeordnete CT gesendet (1706). 
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In einer CT mittlerer Hierarchieebene lauft die Obersetzung der Trigger ahnlich Fig. 1, rnit der Ausnahme, daB Trig- 
gervektoren und E> Vektoren gemaB Fig. 14 behandelt werden. Die KR/EKR werden gemSB Fig. 2 geladen, mil der Aus- 
nahme, daB die Datenworte nicht nur in das eigene CTR geschrieben werden (0210), sondem gleichzeitig an die unter- 
geordnete CT gesendet werden. 

Fig. 19 verdeutlicht das FILMO Prinzip. Der FELMO (1901) wird bei lesenden und schreibenden Zugriffen immer 5 
vom Anfang zum Ende durchlaufen (1902). Werden Eintrage vom Anfang des FILMOs geschrieben und geloscht 
(1903), wird der Lesezeiger auf den ersten ungeloschten Einlrag verschoben (1904). Werden Eintrage aus der Mitte das 
FTLMOs geschrieben (1905), bleibt der Lesezeiger unverandert (1906), die Eintrage werden mit "NOP" markiert (1907) 
Werden Daten in das FILMO geschrieben (1908), werden diese am Ende, hinter dem letzten Eintrag angehangt (1909). 
Der Lesezeiger (1910) bleibt unverandert. 10 

Selbstverstandlich kann eine CT mit nur einem Speicher, der LUT1, LUT2 und CTR umfaBt aufgebaut werden. Die 
Steuerung dafur ist jedoch aufwendiger. Die CIs sind dabei ahnlich der ROOT-CT aufgebaut, die bereits die LUT2 UND 
das CTR im ECR integriert. Fiir das Verstandnis des Verfahrens ist eine Beschreibung dieser CIs nicht erforderlich. 

Wird eine CT als Cachesystem fur Daten eingesetzt, werden Trigger zum Schreiben von Daten in das CTR eingefuhrt 
Dabei werden die Daten von einer CEL in das CTR geschrieben. Die hierzu notwendigen Andemngen sind trivial, das 15 
FILMO kann komplett entfallen. 

Beim Cachen der Daten tritt das Problem der Datenkonsistenz auf. Dies kann umgangen werden, indem ein Verfahren 
gemaB DE 42 21 278 Al eingesetzt wird, urn die Daten und deren Gultigkeit in den einzelnen Hierarchieebenen zu kenn- 
zeichnen. Werden Daten zurDurchfuhrung eines Read-Modify- Write-Zyklusses (RMW-Zyklus) angefordert, werden die 
Daten auf alien Hierarchieebenen anhand eines zusatzlichen Eintrages in dem CTR/ECR als "ungultig" (INVALID) ge- 20 
kennzeichnet. In den Eintrag kann dazu die eindeutige ID der die Daten benutzenden KR/IKR eingetragen werden. Die 
Daten konnen so lange von keiner KR/IKR mit anderer ID benutzt werden, bis die die Daten benutzende KR/KR die Da- 
ten zuriickgeschrieben (vgl. Write-Back-Methode nach dem Stand der Technik) und ihre ID geloscht hat. 

Fig. 20 zeigt ein Ausfuhrungsbeispiel: 

In Fig. 20a fordert die CT 2007 Daten von der dariiberliegenden CT an, diese fordert die Daten von der ROOT-CT 25 
2004; mit der Datenanforderung wird die ID der Anfordemden KR/IKR (2001) ubertragen. Die Daten (2002) werden an 
2007 gesendet. Alle anderen, spateren Zugriffe werden abgewiesen (2003). 

In Fig. 20b werden die Daten zuriickgeschrieben (2005), anderen, spateren Zugriffe werden wieder akzeptiert (2006) 
In Fig. 20c werden Daten von einer CT mittleren Hierarchie angefordert, im Besitz der Daten ist und diese an 2007 sen- 
det. Die ID zum Sperren der Daten wird an alle Cft in der Hierarchie gesendet (2001). Beim Ruckschreiben der Daten 30 
(Write-Back) in Fig. 20d werden die Daten an alle CTs in der Hierarchie geschrieben und die ID geloscht. 
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Begriffsdefinition 

Broadcast: Senden einer Information an eine Vielzahl von Empfangern. 
30 Datenempfanger: Die Einheit(en), die Ergebnisse der CEL weiterverarbeitetAarbeiten 

Datensender: Die Einheit(en), die Daten fur die CEL als Operanden zur Verfugung stellt/stellen 

Datenwort: Ein Datenwort besteht aus einer beliebig langen Bit-Reihe. Diese Bit-Reihe stellt eine \ferarbeitungsein- 

heit fur eine Anlage dar. In einem Datenwort konnen sowohl Befehle fur Prozessoren o.a. Bausteine sowie rein Daten ko- 

diert werden. 

35 Deadlock: Zustand, indem aufgrund gegensei tiger Blockade keinerlei Daten verarbeitung moglich ist. 
DFP: DatenfluBprozessor nach Patent/OfTenlegung DE 44 16 881 
DPGA: Dynamisch konfigurierbare FPGAs. Stand der Technik 

Elemente: SammelbegrifT fur alle Arten von in sich abgeschlossenen Einheiten, welche als Stuck in einem elektroni- 
schen Baustein zum Einsatz kommen konnen. Elemente sind also: 

40 

- Konfigurierbare Zellen aller Art 

- Cluster 

- RAM-Blocke 

- Logik 

45 - Rechenwerke 

- Register 

- Multiplexer 

- I/O Pins eines Chips 

50 Ereignis: Ein Ereignis kann durch ein Hardwareelement in irgendemer zur Anwendung passenden Art und Weise aus- 
gewertet werden und als Reaktion auf diese Auswertung eine bedingte Aktion auslosen. Ereignisse sind somit zum Bei- 
spiel: 

- Taktzyklus einer Rechenanlage. 

55 - internes oder externes Interrupt-Signal. 

- Trigger-Signal von anderen Elementeh innerhalb des Bausteines. 

- Vergleich eines Datenstroms und/oder eines Befehlstroms mit einem Wert. 

- Input/Output Ereigenisse. 

- Ablaufen, uberlaufen, neusetzen etc. eines Zahlers. 
60 - Auswerten eines Vergleichs. 

FIFO: First-In, First-Out Speicher nach dem Stand der Technik 

FILMO: Abgewandeltes FIFO, aus dem linear Daten gelesen werden. Eine Beschrankung des Lesezeigers auf den Be- 
ginn des Speichers ist nicht vorhanden. 
65 FPGA: Programmierbarer Logikbaustein. Stand der Technik. 

F-FLUREG Register in dem die Funktion der CEL gesetzt wird. Ebenfalls wird der OneShot- und Sleep-Mode gesetzt 
Das Register wird von der PLU beschrieben. 

Fragmentierung: Zerteilen von Speicher in eine Vielzahl oftmals kleiner und damit nutzloser Speicherbereiche. 
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Garbage-Kollektor: Einheit zum Verwalten des Speichers. Verhindert eine Fragmentierung. 
H-Pegel: Logisch 1 Pegel, abhangig von der verwendeten Technologic 
HOST: Einem Baustein oder Baugruppe iibergeordneter Rechner. 

EDLE-Zyklus: Zyklus, in dem eine Statemachine keine Verarbeitung durehfuhrt Grundzustand einer Statemachine. 
Pointer Zeiger auf eine Adresse bzw. ein Datenwort. 5 
konfigurierbares Element: Ein konfigurierbares Element stellt eine Einheit eines Logik-Bausteines dar, welche durch 
ein Konfiguiationswort fiir eine spezielle Funktion eingestellt werden kann. Konfigurierbare Elemente sind somit, alle 
Arten von RAM Zellen, Multiplexer, Arithmeusche logische Einheiten, Register und alle Arten von intemer und externer 
Vernetzungsbeschreibung etc. 

konfigurierbare Zelle: Siehe Logikzellen 10 
Konfigurieren: Einstellen der Funktion und Vemetzung einer logischen Einheit, einer (FPGA>Zelle oder einer GEL 
(vgl. umkonfigurieren). 

Konfigurationsdaten: BeLiebige Menge von Konfigurationsworlen. 

KonfigurationsrouUne: Mehrere Konfigurationsworte zu einem Algorithmus zusammengefugte. 

Konfigurationsspeicher. Der Konfigurationspeicher enthalt ein oder mehrere Konfigurationsworte. 15 

Konfigurationswort: Ein Konfigurationswort besteht aus einer beliebig langen Bit-Reihe. Diese Bit-Reihe stellt eine 
gultige Einstellung fiir das zu konfigurierende Element dar, so das eine funktionsfahige Einheit entsteht. 

Ladelogik: Einheit zum Konfigurieren und Umkonfigurieren der CEL. Ausgestaltet durch einen speziell an seine Auf- 
gabe angepaBten Mikrokontroller. 

Logikzellen: Bet DFPs, FPGAs, DPGAs verwendete konfigurierbare Zellen, die einfache logische oder arithmetische 20 
Aufgaben gemafi ihrer Konfiguration erfullen. 

Lookup-Tabelle: Stand der Technik. Verfahren zum {Jbersetzen von Daten. 

L-Pegel: Logisch 0 Pegel, abhangig von der verwendeten Technologic 

Maske: Bitkombination, die die gultigen Signale innerhalb einer Mehrzahl von Signalen angibt. 

PLU: Einheit zum Konfigurieren und Umkonfigurieren der CEL. Ausgestaltet durch einen speziell an seine Aufgabe 25 
angepaBten Mikrokontroller. 
Priorisierung: Festlegung einer Reihenfolge. 
PECONF1G: Rekonfigurierbarer Zustand einer CEL. 
RECONFIG-Triggen Setzen einer CEL in den rekonfigurierbaren Zustand. 

REMOVE-<ID>: 1 . Befehl innerhalb eines KR zum Entfemen der durch ID referenzierten KR. 2. Befehl einer iiber- 30 
geordneten CT iiber ein separates Interface oder Handshaking an eine untergeordnete CT zum loschen der durch ID re- 
ferenzierten KR. 

RESET: Rucksetzen eines Bausteines oder eines ganzen Computersystems in einen definierten Grundzustand. 
ROOT-CT: CT der hochsten Hierarchieebene mit direktem Zugriff auf den extemen Konfigurationsspeicher. 
Round-Pobin-Arbiten Arbiter der im Kreis lauft und immer dem zuletzt arbitrierten Signal die niederste Prioritat zu- 35 
ordnet. 

Statemachine: siehe Zustandsmaschine. 

Switching-Tabelle: Eine Switching-Tabelle ist ein Ring-Speicher, welcher durch eine Steuerung angesprochen wird. 
Die Eintrage einer Switching-Tabelle konnen beliebige Konfigurationsworter aufnehmen. Die Steuerung kann Befehle 
durchfuhren. Die Switching-Tabelle reagiert auf Triggersignale und konfiguriert konfigurierbare Elemente anhand eines 40 
Eintrages in einem Ringspeicher um. 

Synchronisationssignale: Statussignale die von einem konfigurierbaren Element oder einem Rechenwerk generiert 
werden und zur Steuerung und Synchronisation der Datenverarbeitung an weitere konfigurierbare Element oder Rechen- 
werke weitergeleitet werden, Es ist auch moglich ein Synchronisationssignal zeitlich verzogert (gespeichert) an ein und 
dasselbe konfigurierbare Element oder Rechenwerk zuruckzuleiten. 45 

Terminierung: Beendigung eines Vorganges, einer Verarbeitung. 

TRIGACK/TRIGRDY: Handshake der Trigger. (Vgl. Handshake der Daten aus PI 965 1075.9) 
TYigger: Synonym fur Synchronisationssignale. 

Umkonfigurieren: Neues Konfigurieren von einer beliebigen Menge von CELs wahrend eine beliebige Restmenge von 
CELs ihre eigenen Funktionen fortsetzen (vgl. konfigurieren). 50 

Verarbeitungszyklus: Ein Verarbeitungszyklus beschreibt die Dauer, welche von einer Einheit benotigt wird, um von 
einem definierten und/oder giilugen Zustand in den nachsten definierten und/oder gultigen Zustand, zu gelangen. 

Zellen: Synonym fur konfigurierbare Elemente. 

Zustandsmaschine: Logik, die diversen Zustanden annehmen kann. Die Obergange zwischen den Zustanden sind von 
verschiedenen Eingangsparametern abhangig. Diese Maschinen werden zur Steuerung komplexer Funktionen eingesetzt 55 
und entsprechen dem Stand der Technik. 

Patentanspriiche 

1. Verfahren zum deadlockfreien, automatischen Konfigurieren und Re konfigurieren von Bausteinen mit zwei- 60 
oder mehrdimensionaler Zellanordnung (z. B. FPGAs, DPGAs, DFPs gemaB DE 44 16 881 Al, o. dgl.), dadurch 
gekennzeichnet, daB eine Einheit zur Steuerung der Konfiguration und Rekon figuration eine Menge von zugeord- 
neten konfigurierbaren Elementen verwaltet, wobei die Menge eine Teilmenge aller konfigurierbaren Elemente oder 
die Gesamtmenge aller konfigurierbaren Elemente ist, und die Verwaltung wie folgt ablauft 

1.1 Rekon figurationsanforderungen von den zugeordneten konfigurierbaren Elementen an die Einheit gesen- 65 
det werden 

1.2 die Einheit die Anforderungen bearbeitet, indem 

a) keine weiteren Anforderungen und Veranderungen wahrend der Ausfuhrung akzeptiert werden, 
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b) die noch zu ladenden Konfigurationsdaten bestehender fruherer Anforderungen aus einem Zwischen- 
speicher (FILMO) in die konfigurierbaren Elemente geladen werden, 

c) die bestehende Anforderung auf eine eindeutige Kennung (ID) umgesetzt wird 

1.3 die ID auf die Adresse der zu ladenden Konfigurationsdaten im Speicher der Einheit umgesetzt wird, so- 
5 fern die Konfigurationsdaten im Speicher der Einheit existieren, 

1.4 die Konfigurationsdaten mit der entsprechenden ID bei einer ubergeordneten Einheit angefordert und ge- 
laden werden, sofem die Konfigurationsdaten nicht im Speicher der Einheit existieren, 

1.5 die Konfigurationsdaten in die konfigurierbaren Elemente geladen werden, sofern die konfigurierbaren 
Elemente die Daten annehmen konnen, 

10 1.6 die Konfigurationsdaten der konfigurierbaren Elemente, die die Daten nicht annehmen konnen in einen 

Zwischenspeicher geladen werden, 

1 .7 nachdem die Konfigurationsdaten vollstandig abgearbeitet sind, wieder neu auftretende Anforderungen 
akzeptiert werden, wobei bis zum Auftreten einer erneuten Anforderung die noch zu ladenden Konfigurations- 
daten bestehender fruherer Anforderungen aus einem Zwischenspeicher (FILMO) in die konfigurierbaren Ele- 
15 mente geladen werden. 

2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, daB Konfigurationsdaten, die nicht an die konfigurierbaren 
Elementen angenommen worden sind, an das Ende des Zwischenspeichers geschrieben werden. 

3. Verfahren nach Anspruch 1 und 2, dadurch gekennzeichnet, daB Konfigurationsdaten zum Schreiben in die kon- 
figurierbaren Elemente vom Anfang zum Ende des Zwischenspeichers gelesen werden, wobei der Zwischenspei- 

20 cher immer komplett durchlaufen wird. 

4. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, daB Konfigurationsdaten, die am Anfang des Zwi- 
schenspeichers in die konfigurierbaren Elemente geschrieben werden, im Zwischenspeicher geloscht werden, d. h. 
der Lesezeiger wird hinter die geschriebenen Daten gesetzt. 

5. Verfahren nach Anspruch 1 bis 4, dadurch gekennzeichnet, daB Konfigurationsdaten, die aus der Mine des Zwi- 
25 schenspeichers in die konfigurierbaren Elemente geschrieben werden, 

a) entweder im Zwischenspeicher als geloscht markiert werden und damit bei einem emeuten Lesedurchlauf 
ubersprungen werden, 

b) oder im Zwischenspeicher (FILMO) geloscht werden, indem die noch existierenden Konfigurationsdaten 
ausgehend von der zu loschenden Speicherstelle bis zum Anfang oder zum Ende des Zwischenspeichers (F1L- 

30 MOs) so verschoben werden, daB die geloschte Speicherstelle mit bestehenden Konfigurationsdaten belegt ist 

und die Zeiger auf den Beginn oder das Ende des Speichers entsprechend angepaBt werden. 

6. Verfahren nach Anspruch 1 bis 5, dadurch gekennzeichnet, daB eine Zustandsmaschine (Garbage- Kollektor) den 
Speicher (CTR) der Einheit so verwaltet, daB keine Speicherlucken entstehen, indem Speicherlucken mit existieren- 
den Konfigurationsdaten ausgehend vom Beginn der Speicherlucke bis zum Ende des Speichers (CTR) so verscho- 

35 ben werden, daB die geloschte Speicherstelle mit bestehenden Konfigurationsdaten belegt ist und die Zeiger auf das 

Ende des Speichers und die Obersetzung der IDs auf verschobene Speicherstellen entsprechend angepaBt werden. 

7. Verfahren nach Anspruch 1 bis 6, dadurch gekennzeichnet, daB bei der Einheit eingehende Anforderungen auf 
eine eindeutige Kennung (ID) einer Konfigurationsroutine ubersetzt wird, und die ID auf eine Speicherstelle im 
Speicher (CTR) zeigt. 

40 8. Verfahren nach Anspruch 1 bis 7, dadurch gekennzeichnet, daB Konfigurationsdaten das Laden weiterer Konfi- 

gurationsdaten bewirken (EXECUTE). 

9. Verfahren nach Anspruch I bis 8, dadurch gekennzeichnet, daB Konfigurationsdaten mittels Anforderung an eine 
andere Einheit das Ausfuhren weiterer Konfigurationsdaten in der anderen Einheiten bewirken (TRIGGER), wobei 
die Anforderungen 

45 a) als Broadcast an alle anderen Einheiten gesendet werden, 

b) nur an die direkt ubergeordnete Einheit gesendet werden, 

c) nur an die direkt untergeordnet(n) Einheit(en) gesendet werden 

d) an eine bestimmte, adressierte Einheit gesendet werden. 

10. Verfahren nach Anspruch 1 bis 9, dadurch gekennzeichnet, daB die Einheiten hierarchisch in einer Baumstruk- 
50 tur angeordnet sind: 

1 1 . Verfahren nach Anspruch 1 bis 10, dadurch gekennzeichnet, daB die hochste Einheit in der Baumstruktur einen 
gemeinsamen Speicher mit einem ubergeordneten Rechner teilt und der ubergeordnete Rechner die Ablaufe in dem 
Baustein uber Kommunikation mit der ubergeordneten Einheit steuert. 

12. Verfahren nach Anspruch 1 bis 11, dadurch gekennzeichnet, daB Einheiten rnittlerer und hochster Hierarchie- 
55 ebene neben gewohnlichen Anforderungen (Trigger) auch auf Anforderungen von IDs reagieren, wobei die ttber- 

setzung der ID in die Adresse der Speicherstelle der referenzierten Konfigurationsroutine erfolgt und die Oberset- 
zung eines Triggers in eine ID entfallt. 

13. Verfahren zum Cachen von Daten und Befehlen in aus mehreren Rechenwerken bestehenden Mikroprozesso- 
ren und in Bausteinen mit zwei- oder mehrdimensionaler Zellanordnung (z. B. FPGAs, DPGAs, DFPs gemaB 

60 DE 44 16 881 Al, o. dgl.), dadurch gekennzeichnet, daB 

13.1 mehrere Zellen und Rechenwerke (CEL) zu einer Mehrzahl von Gruppen zusammengefaBt werden, wo- 
bei jeder Teilgruppe ein Cache (CT) zugeordnet ist, 

13.2 die Caches der einzelnen Teilgruppen werden uber eine Baumstruktur an einen ubergeordneten Cache 
(ROOT-CT) geschaltet, der ZugrifT auf einen Speicher (ECR) besitzt, in dem die Daten/Befehle abgelegt sind, . 

65 1 3.3 jeder untergeordnete Cache oder Cache auf rnittlerer Ebene des Baumes fordert die benotigten Daten/Be- 

fehle bei dem jeweils ubergeordneten Cache an, 

13.4 die Daten werden Uber einen Write-Through-Mechanismus an die ubergeordneten CTs und in den Spei- 
cher (ECR) geschrieben werden, 
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1 3.5 die Daien werden wahrend des Zugriffes durch eine KR/EKR in alien CTs durch Eintragen der ID der be- 
treffenden KR/TKR in das CTR/ECR als "ungultig" markiert, 

1 3.6 beim Ruckschreiben der Daien wird die ID in dem zusatzlichen Eintrag des CTR/ECR geldscht, wodurch 
die Daten als giiltig markiert sind. 

14. Verfahren zum Arbitrieren von Daten dadurch gekennzeichnet, dafl 5 

14.1 die zu arbitrierenden Signale iiber eine Maske auf einen Round-Robin-Arbiter geleitet werden, wobei der 
Grundzustand der Maske alle Signale durchschaltet, 

14.2 der Arbiterausgang gibt das arbitrierte Signal an, 

143 das arbitrierte Signal wird so dekodiert und auf die Maske zuriickgefuhrt, daB das Signal und alle anderen 
hoherpriorisierten Signale von der Maske gespent werden, 10 
14.4 ist das letzte Signal arbitriert oder es existiert kein von der Maske freigeschaltetes Signal, das eine Arbi- 
trierung anfordert, wird die Maske komplett freigeschaltet 



Hierzu 21 Seite(n) Zeichnungen 

15 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



19 



ZEICHNUNGEN SEITE 1 Nummer: DE19807872A1 

IntCI. 6 : G06F 15/80 

Offenlegungstag: 26. August 1999 



o 




E 

Z3 



c h- 

<B uj o 
o 









e 


c 




=5 


o 


s 




cr 














902 034/438 



ZEICHNUNGEN SEITE 2 Nummer: DE 198 07 872 A1 

Int. CI. 6 : G06F 15/80 

Offenlegungstag: 26. August 1999 



(N 




902 034/438 



ZEICHNUNGEN SEITE 3 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE19807872A1 
G06F 1^/80 

26. August 1999 



.O) J- 

*- JZ 
"D CD 

c IE 

CO 



CO 



£ ^ q: 

r- w 

2 | 
o 

CO 



I 

CD 



CO 

.si 




CO 

.Si 



902 034/438 



ZEICHNUNGEN SEITE 4 



Nummer: 
Int. CL 6 : 

Offenlegungstag: 



DE19807872A1 
G06F 15/80 

26. August 1999 





S3 
I*, 



902 034/438 



ZEICHNUNGEN SEITE 5 



Nummer: 
Int CI. 6 : 

Offenlegungstag: 



DE198 07 872A1 
G06F 15/80 
26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 6 Nummer; DE19807872A1 

Int. CI. 6 : G 06 F 15/80 

Offenlegungstag: 26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 7 Nummer: DE 198 07 872 A1 

Int. CI. 6 : G 06 F 15/80 

Offenlegungstag: 26. August 1999 




o 
o 



+ 
+ 

CL 
Q. 



rii $5*= i 









l_ 








<D 








D) 


UJ 






D) 


-J 








g 






x: 






O 


o 






o 


to 
_i 




9 



> 
O 

E 

(D 




902 034/438 



ZEICHNUNGEN SEfTE 8 



Nummer: 
IntCI. 6 : 

Offenlegungstag: 



DE198 07 872 A1 
G06F 15/80 

26. August 1999 



O 3 

£ 3 

DO > 







CO 


o 




o 


oo 




00 


o 




o 




\8§8§ 



oo 

•§> 
fan 



O 
1 



X 
I 

I 
I 
I 
I 
I 
I 



c c 

CO 



902 034/438 



ZEICHNUNGEN SEITE 9 



Nummer: 
Int CI. 6 : 

Offenlegungstag: 



DE19807 872A1 
G06F IS/80 

26. August 1999 



CO 
ON 

o 



CO 

o 

On 
O 



CN 
CD 

& 



CM 
^ — i 

OV 

o 




3 

o ^ 

O) O) = 



3 

O 

CO 

</> 

<D 

DC 



3 

o 

V) 

w 
X 



3 

o 

C 
LU 
O 



On 



fl 




902 034/438 



ZEICHNUNGEN SEITE 10 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE 19807 872 A1 
G06F 1^/80 

26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 11 Nummer: DE 19807 872 A1 

IntCI. 6 : G 06 F 15/80 

Offenlegungstag: 26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 12 



Nummer: 
Int. CI* 

Offenlegungstag: 



DE 198 07 872 A1 
G06F 15/80 

26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 13 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE19807872A1 
G06F 15/80 

26. August 1999 



^3 
(N 



CN 
O 
CN 



O 

CN 



in 
o 

<N 



CO 
O 
CN 



CO 

o 

CN 



CO 

o 

CN 



CO 

o 

CN 



CN 
O 
CN 



O 

CN 







O 




<N 




r-H 




i 


\ 














o 






CN 






r— I 



CO 

o 

CN 



CO 

o 

CN 





00 




o 




CN 






CO 




o 




CN 




r— I 



CN 
O 
CN 



CN 
O 
CN 



902 034/438 



ZEICHNUNGEN SEITE 14 Nummer: DE 19807 872 A1 

IntCI. 6 : G 06 F 15/80 

Offenlegungstag: 26. August 1999 




CO 



902 034/438 



ZEICHNUNGEN SEITE 15 



Nummer: 
Int CI. 6 : 

Offenlegungstag: 



DE19807 872A1 
G06F 19/80 

26. August 1999 




902 034/438 




902 034/438 



ZEICHNUNGEN SEITE 17 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE198 07 872A1 
G 06 F 15/80 

26. August 1999 



CO 
CO 

CD 
>— 

T3 
< 



DC 

O 
HI 



DC 
O 
UJ 

=> 



DC 
Q 
< 

O 

o 

CD 



DC 
DC 



o 



<D 

or 





— 






CTR 


-J 


g 


ZD 
_J 


dress 



<3 



1^ 



3 



902 034/438 



ZEICHNUNGEN SEITE 18 Nummer: DE 19807 872 A1 

Int. CI. 6 : G 06 F 15/80 

Offenlegungstag: 26. August 1999 



+ 
+ 

CL 
LL 




X 
CO 

E 

o 

A 

Dl 
LL 




CN 

O! 
CN 
O! 



CO 



LU 
> 

o 



c 

CD 

a: 



LU o 



r 



c/> 

CD 



CO 

o 

cN 
O 




Q_ 

o 

h- 

c/) 

"E 
o 



o 
c 



CN 



CN 
O 



® 

LL 


in LUT2 


"ore 


g 


CO 


Adn 



£ 




o 








CO 




Da 


EC 


■o 




CO 




CD 










O 
CN 
O 






1502 




► 


A 
i 




co 


g 




o 




o 


t> 










T— 1 




902 034/438 



ZEICHNUNGEN SEITE 19 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE198 07 872A1 
G06F 15/80 

26. August 1999 




902 034/438 



ZEICHNUNGEN SEITE 20 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE19807872A1 
G06F 15/80 

26. August 1999 



CO 

o 

On 

n 



on! 



o; 

T-HI 



at 



00 

o 

On 



O 

ON 



O 

ON 



wn in 
o o 

ON On 



t t 



aft 

on; r- o 
^ o o 

C\ ON 



902 034/438 



ZEICHNUNGEN SEITE 21 



Nummer: 
Int. CI. 6 : 

Offenlegungstag: 



DE19807 872A1 
G06F 15/80 

26. August 1999 





902 034/438 



